Laptop Based on 6502 CPU(maddox.pro) |
Laptop Based on 6502 CPU(maddox.pro) |
Specs:
* 65C02 running at 10MHz
* 46KByte of user RAM
* EhBASIC 22p2 with custom extensions
* eWOZMON
* Compact Flash for storage
* Built in battery (7400mAh currently)
* USB-PD Rechargable
* 10.1" Screen with 1024x600 and 256 colours
* WiFi Modem (based on this - https://github.com/dhansel/WifiModem)
* nanoSwinSID for sound (as well as beeps)
Turns out it looks awesome. I wasn't expecting such a striking design.
Back in the day 48K got used as a way of binning in the ZX Spectrum (Z80 based) to make use of cheap "bad" memory. Surely RAM prices aren't that crazy now? :P
but it looks like the LCD has to be bit banged by the CPU data bus directly? I see the 8 bit data bus is going straight to the LCD thru a buffer IC.
I don't see where in the memory map there would even be enough space for a screen buffer that large to be located, so I take it you have to write you own graphics handling yourself and pick a spot in memory for it all?
A description (from https://www.raio.com.tw/en/RA8889.html):
> RA8889 is a low power TFT controller with powerful display functions and build-in internal SDRAM memory. In order to quickly refresh the screen content with the display memory, RA8889 provides not only parallel, 8080/6800 8/16-bit MCU interface, but also 3/4 wire SPI and IIC serial interface. Plenty powerful functions are provides from RA8889, such as multiple display buffers, Picture-in-Picture, transparency control, display with rotation & mirror, and build-in JPEG and AVI decoder.
> I don't see where in the memory map there would even be enough space for a screen buffer that large to be located
1024 × 600 with 256 colours is 600 kB. Even in monochrome, it would be over 64 kB.
> but it looks like the LCD has to be bit banged by the CPU data bus directly?
Even at 20 Hz, that would involve writing over a ten million pixels per second, giving you about 1 CPU cycle per pixel ⇒ there’s no way to do that with this CPU.
Browsing by tag 'lt6502b' gives other posts that have pictures of the motherboard. https://www.maddox.pro/?cat=65 (update: the codeberg link has all the relevant pics)
Yes, 128 bytes. Used for code, data, video, and everything else.
(But it can address 64 KB)
It is so primitive that it is unable to multiply integers. If you want to multiply, you have to write your own algorithm.
Also, for those with deep pockets there were the GRiD laptops....
Apple IIc (https://en.wikipedia.org/wiki/Apple_IIc)
and it's younger and final brother Apple IIc Plus (https://en.wikipedia.org/wiki/Apple_IIc_Plus)
Perfect for some poolside work.
Edit: Okay, I was actually thinking of the Apple IIgs, which came out 2 years later. Both a similar design, though, and much nicer looking than the older Apples.
It would give the laptop a great deal of structural support and act as a secure place to mount the hinges (for example). Also a convenient surface to perhaps integrate with the heat sinks to pull heat out of the enclosure.
The Z80 has likewise experienced the same use: https://hackaday.io/project/166921-v-tech-genius-leader-prec...
Every machine ran BASIC. If your machine didn't, it was weird. For a while it seemed like BASIC was going to become the universal computer language.
IBM even produced a computer that had both AP/L and BASIC built-in.
Surely a laptop prototype based on such a tested and well-worn CPU with 48K of RAM would be cool, but shouldn't it sip power? Like shouldn't it last for like months on a charge? Or am I revealing my very meager and outdated understanding of engineering with only a bachelor in computer science from like 2004?
If you ran a 6502 emulator on a cheap ARM SOC, it would be much lower power.
Also, the 100LX with monochrome CGA (80x24, 640x200), a 7.91 MHz 80186-compatible CPU, and 1MB or 2MB of RAM but the extra was used for file storage as drive C:.
The 200LX was the same as the 100LX but had newer software in ROM.
Also, Microchess from the Kim-1 could be ported in a weekend on that.
sheesh.
(Disclaimer: I’m a huge fan of her work, still get one of the original Monowave prototypes in my rack, I delight in seeing her projects come to fruition)
My Oric Atmos with LOCI rig has every bit of software every developed for the Oric, ever, stored on its 8GB USB stick and literally has ~8GB left in storage. It used space is more like a rounding error at this point.
I hope that changes, though! ;)
Old computers never die - their users do!
Paula’s intention, I believe, is to make computing approachable again - her many, many synthesizer designs encode a form of nostalgic whimsy for older technology, and she produced a full-scale CPU project using only logic chips for the purposes of education - and as I know she is a huge UFO (TV Series) fan, she’s got a fair bit of creative potential being applied to the alt-computing track of things.
As a retro- nerd myself, I hope to see her laptop in action in real life some day. Would be awesome to see an Oric-1/Atmos ROM for it ..
Unless you use bank switching, which historically a lot of 6502 machines did use (e.g. Apple III/IIe/IIc, BBC Master 128, Commodore 128, Commodore CBM-II, etc)
The C64 actually had 64K of ram, 4k of devices (graphics, sound etc) and 16K of ROM.
Incidentally, cheap MP3/MP4 players in the last decade had a few hundred KB of RAM, an 8-bit CPU at a few dozen MHz, and a few GB of NAND flash: https://en.wikipedia.org/wiki/S1_MP3_player
The 80C51 is just never going away is it? I mean there's no reason for it to.
This machine indeed has 128 bytes of RAM, but the code and data live on the cartridges, which can include up to 64 KB of ROM (exposing 4 KB at a time, with bank switching). Also, graphics is created on the fly ("racing the beam") at TV display, so there's no need to spend precious RAM on the framebuffer.
In comparison to the later constructions based on the 6502, like NES or C64, it was certainly not an easy platform to develop games, but not as hard as your comment is suggesting.
That's a weird thing to say. There are a lot of otherwise quite sophisticated chips that don't do multiplication. Multiplication is a pretty high bar, so the 6502 coming in below isn't much of a surprise.
Has the situation here really gotten so bad that no one can tell at a glance that they're responding to mindless LLM texts?
It's so primitive that it can be understood.
Relevant fun:
It sometimes seems that all we have done over that period is add layers and layers of complexity.
The machine itself was not necessarily faster, but the extra memory was a real game changer.
Even segmented like on the 8086 was a better solution than the banking options on 8 bit hardware. The ‘86 segment registers were much more flexible.
Long term, 640k may not have been enough, but in a text based environment, 640k is just so much more from both a data and code aspect to be really empowering.
256k and Lotus 1-2-3 was much more capable than anything an Apple could do. Having much more room for more capable code aspect as well as richer and more data.
You could do gymnastics with code overlays and data paging, but that was hard software to write and just painfully slow.
Extra memory just made things that much better.
I don't think anybody would use such a machine full-time, but with a radio and a cabin it would suffice for offline work.
Of course there's no native CP/M for the 6502, but remakes have been made..
Because most people I know certainly have different workloads and need their rendering as part of the work, not to decorate it nicely.
But for keeping a distraction free digital diary, it might be a nice device.
Maybe Bullshit Jobs was onto something, it seems that my entire work day consists of work decoration.
EDIT: mentioning the Apple IIc (and later IIgs) as was done else-thread would've been more on-topic.
Might have been interesting if they'd allowed you to page out the ROM to access the extra 16K - load a small routine from tape that contains your own tape loading routine, swap out the ROM, load the rest of your app, bob's your uncle. Would have needed some shenanigans to swap in the ROM on reset, obvs.
[0] http://www.breakintoprogram.co.uk/hardware/computers/zx-spec...
> One of the future goals is to copy the ROM and RAM and switch it out of the address space.
Like the BBC Micro Sideways RAM system? Nice.
6502 emulators can easily detect dumb endless loops, and that can turn into what's basically a Z80 HALT.
As for the goal of making systems which cannot run AI - this goal has always been intrinsically fulfilled by Moores law. For as long as we were progressing towards the singularity, we were incapable of it. Whether that is of importance now, as if it were ever not, is a matter of interest in the results: do we panic about AI now, or 20 years ago?
I think that there is enough of Paula Maddox out there to prove we don’t really need AI to do great things, just great people.
For something more modern, have a look at how the basic variants of Risc-V don't include multiplication.
A very basic pocket calculator might not have multiplication as an instruction, but multiply by running a simple multi-instruction program. That's how people multiplied on a 6502, too. (Similar also for calculation cosine or square-roots or logarithms: you run a little program.)
First, they're more granular. Segment represents 16 byte blocks, most banking systems had 4K blocks.
Second, the segments can overlap. The most basic example is the Tiny model where CS and DS are identical. 64K of shared code and data. Separate them, and you can have 64K of code and 64K of data with almost no code changes. (The Small memory model).
Third, you can move memory between segments. With banks, the typical setup if you wanted to move data from Bank A to Bank B, you had to move it out of Bank A, enable Bank B, and then move it back in. Obviously with more sophisticated banking architecture, you can do whatever you want. Eventually you creep into more of a MMU logic than simple banking.
Finally, somewhat related to the previous, you have the ES, Extra Segment. While more limited than the CS/DS in terms of capability, it was enough to let you shove things around without having to clobber your CS/DS if you didn't want to. Saved a bit of juggling there.
Regarding the part about code spanning, yeah, that's an issue in terms of continuity. You simply couldn't have code that was larger than 64K, the PC will wrap on the CS.
But, you had direct support for "far pointers". You could "Jump" to SSSS:XXXX, storing the entirety of the pointer, and do a far jump directly. The jump resets the CS for you. You can't do that with a banked system. You're responsible for banking things in at the right time. So, if you commit to far pointers for all of your function calls, the code just links and it "just works" without you having to do anything manually.
More expensive of course, so folks would make internal little worlds of code and data and contextually bounce between them. But you have the option of not having to do that if you didn't want to.
Banking registers also weren't always readable, in which case either you'd need to shadow the banking register or avoid nested/interrupt scenarios.
I'd prefer 8086 segmentation any day over the headache of trying to execute 6502 code from a bank-switched cartridge with a single banking window and a write-only banking register.
What makes the CBM-II's 6509 fundamentally different from the C128's 8502+8722 combo? And what makes either fundamentally different from the segmentation scheme of the 8086/8088?
Aha, step forward the Jupiter Ace...
In that sense I'd regard it as a remake, rather than a port. But it's impressive it is possible at all, and it does look like a fun project. (I remember watching some of the porting/building videos when I was working on my own understanding of CP/M for emulation purposes.)
We had record players for that, and Walkmans for when we were out and about.
As late as 1997 I was repairing Amstrad PCWs that were still in Real Live Active Service on oil platforms.
And then after that, I was reading those funny 3" disks in and converting them to WordPerfect.
And then from WordPerfect to Word, a little later.
Be the guy selling shovels I guess.
tl;dw - The background is defined with 20 bits, which are repeated or mirrored to make the background (eg 00000000111111110000 would either make the background 0000000011111111000000000000111111110000 or 0000000011111111000000001111111100000000). If you write to WSYNC ($D40A), the processor pauses until the start of the next scanline. Then you have to count machine cycles to make sure you modify the background at the right time to make the two halves different. Repeat on each scanline to fully define the background. There is no "framebuffer" per se
You still needed a counter (index) to determine which byte in the ROM to copy over. You probably also wanted to put the graphics bitmap data at the beginning of a page (e.g. $FD00) so you would only need to increment 1 byte in the pointer and not worry about carrying over to the next byte.
The horizontal resolution was 160, and generally you were generating less than 255 lines of graphics, so tracking the X and Y position only took 2 bytes, and maybe a few other bytes for metadata.
Essentially, the 2600 gives the programmer 2 sprites only. One sprite is dedicated to drawing the Pac-Man main character, while the other takes the role of all four ghosts. That's right, simultaneously 1 sprite for 4 distinct ghosts, wherever they are on the screen.
This singular sprite and the practice of "racing the beam" leads to a lot of flickering. I believe that the flickering is so severe that it impacts the collision detection, so that Pac-Man can slide right through a ghost in the right place and time.
I owned a copy, of course, and it was just so sad to compare it with its daddy in the arcade cabinet. However, once Ms. Pac-Man rolled around, they had learned a lot of lessons, and made that one a rousing technical success.
The signature hack on the system is to reuse sprites mid-frame. That's the "racing the beam": after an object has been drawn, reposition the sprite to draw something else further down on the screen, before the scanline beam gets there.
Pac-Man didn't do that. Instead, it draws only one ghost sprite per frame, and flickers between the four of them every four frames. The flickering and racing-the-beam are opposites, not one causing the other.
Atari's programmers knew how to race the beam for reusing sprites. Air-Sea Battle did it years before Pac-Man. What's different about Pac-Man is that the objects aren't constrained in their movement. They can overlap on the same scanline which makes drawing multiples with a single sprite impossible. The right solution to this and what Ms. Pac did is smart sprite reuse - if they're on the same scanline, flicker temporarily, but then when they move to be separated vertically, race the beam to display both together. This didn't happen for Pac-Man because Atari rushed it to release in too short a timeframe to implement that, and also the code wouldn't have fit into a standard 4k cartridge and would have needed more expensive hardware with bankswitching logic chips. 2600 Pac-Man's terribleness was a business decision, not a technical limitation.
First, there is no frame buffer (there could be no such thing in that memory space), but there are effectively line buffers for the different sprite types and background. These are not in the 128 bytes of general purpose RAM but memory mapped to the display controller.
Second, it maintains the patterns in these buffers until you change them and will repeat them on the next line unless you do anything to change them. This makes it easy to perform partial update, e.g. only update the background every 8 lines and only update sprite graphics on odd lines or whatever you need to do to save time.
Third, the video controller can be instructed (via a memory mapped register) to halt the CPU until the next horizontal "blanking" interval. This makes synchronizing to the beam position between lines much easier.
Fourth, there are no interrupts (except NMI, only triggered manually with the brk instruction) so timing is easily predictable.
Fifth, there is a hardware timer which makes it easier to keep track of your budget while in the vertical blanking portion of the screen, where you probably want to handle most if not all of your game logic. That way the game logic doesn't need to be strictly timed in the same way the screen is.
I made a game for it (https://text.garden/jupitersumo.html) expecting it to be difficult, but found that the simplicity and predictable timing made it surprisingly easy. On the C64 for example you will often find yourself wanting to synchronize to the beginning of a line or even every line for one reason or another, but doing that while dealing with the complexities of its timing is a whole science unto itself. For the main game screen I ended up using some 16 bytes of state in RAM to represent the stuff I need to keep track of while "racing the beam". The code that handles the display is maybe 150 instructions long and lives in the game ROM. The source code is linked from the page if you're interested in how it works.
Of course, in terms of what it displays, my game is very simple, only showing a background and the player sprites. There are much more complex display routines ("kernels") in the VCS game library. An interesting example is Pitfall II, which is very impressive considering the platform, but uses a coprocessor on the cartridge itself (called the DPC) to help sequence line register updates. From memory, I think it lets you enqueue data in advance, and during the display routine the CPU can just read a single register to get the next byte from a queue.
There's a lot of myths around 2600 Pac-Man. The game was made in around 5 months, which was a normal amount of dev time for a 2600 game. The ghosts flickering was due to insufficient RAM, not insufficient ROM. Tod Frye, the game's programmer, had a kernel that would reposition the sprites as the screen drew, but it needed additional RAM. Frye really wanted Pac-Man to have a 2-player mode, as the arcade version did and he felt that having a 2-player mode gave the consumer more value. This meant that there wasn't enough RAM to get rid of the flicker, since the game had to keep track of the game state for each player. The 2600 version of Ms. Pac-Man was 1-player only, which is how they avoided the flickering.
