Interesting spec. Why go for 48K of RAM and not at least 64K (the full address space without paging)?
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
Wouldn't this be because the ROM is taking up address space and they don't have bank switching? One of the future goals is to copy the ROM and RAM and switch it out of the address space.
That's how it was on the Spectrum, at least - it had 64k of RAM but the bottom 16K was permanently mapped to the ROM[0].
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.
This was exactly one of the many hardware projects that were published in the spanish magazine microhobby.
Long story short: it added 16K of RAM that was mapped at 0, and allowed both manual control with buttons or software control via a port to decide if it is mapped only for writes or it is mapped for both reads and writes.
My understanding was that Sinclare got to 48K using 8× 4116 + 8× 4532 chips where the 4532 was basically a 64K-bit 4164 where only half the chip worked.
> One of the future goals is to copy the ROM and RAM and switch it out of the address space.
I'm trying to figure out the video part, there is a demo screen that is showing pretty high res in color, and this says 1024x600 and 256 colours- that is mighty impressive for a 6502, that is driving way more pixels that I ever saw in that era, so I was expecting there was some other chip being used as a screen buffer and graphics chip...
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?
> 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 wondered the same thing, and it looks like it uses this CMOS-compatible high level TFT driver: https://www.raio.com.tw/en/RA8889.html with a character generator, geometry primitives, etc.
> 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.
These sorts of project should be using the 68000 or the 65816 which both give a 24 bit address bus. Meaning they get 16 MB of address space to work with. They can make directly addressable frame buffers at high resolutions and reasonable color depths, and still have lots of memory available for programs and data.
Very interesting project. It'd be nice to see video of it in action and what use cases the author had in mind. A pic in a different post shows the 48k ram chip, and not far away is an SD card of 1 gigabyte - that's a dramatic contrast. The storage can hold the contents of ram 21,845 times over. If an 8GB laptop today had the equivalent storage, it would be a disk of 174TB.
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)
In the retro world we’ve already had the incongruent “64k RAM vs 8GB Storage” conundrum to deal with for decades.
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 ..
Oh, it is very much a truth, I agree. The machine is the purpose - you can see it in all of her designs, which are very directed, intentionally, towards well-stated goals.
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.
The 6502 can't actually address more than that. The flash controller built into modern SD cards are also going to be significantly more powerful than the 6502. And I'm surprised you can even buy SD cards that small still!
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)
Quick note that bank switching does not in fact allow the CPU to "address" more than 64K. It allows the machine to "have" more than 64K but only 64K of it can be addressed by the CPU at any time.
The MOS 6509 has bank switching hardware built into the CPU, instead of being on an external MMU chip such as the MOS 8722.
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?
A pic in a different post shows the 48k ram chip, and not far away is an SD card of 1 gigabyte - that's a dramatic contrast
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 8051 is just about 'free' in the sense that all it's patents, etc., have expired. So anyone who says "I need to throw a bit of microcontroller at this problem" can either grab a sub-pennies device or throw a bit of no cost/low cost 8051 IP in a tiny corner of an FPGA or ASIC and leverage 50 something years of experience, tooling, examples, etc. It's not as cool as a ARM or RISC-V, but it serves a purpose.
I assume you're talking about the Atari 2600 console (VCS), which uses a limited version of that CPU, called 6507. It has the addressing space reduced to 16 KB.
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.
The very idea of "racing the beam" is madness distilled. How do you draw without a framebuffer and keep track of everything's position using just 128 bytes of RAM? This comment alone uses more RAM than that.
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
All the code is kept in the rom, as are all the assets. So you only need to track sprites that move unpredictably, and the average 2600 game had very few of those - pacman, space invaders, etc have very few actice objects, and most of them are strictly constrained in how they can move.
I don't know about Space Invaders, but Pac-Man on the 2600 used incredible hacks that were widely criticized, but essential to cramming the spirit of the game into that tiny cartridge and puny machine.
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.
It's the other way around - 2600 Pac-Man didn't do any hacks and that's what made it terrible.
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.
> 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.
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.
Graphics bitmap data was in the ROM - it was copied directly to the TIA's graphics or playfield data registers line by line by the CPU. No intermediate copy-to-RAM needed.
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.
The VCS has some handy features that makes it easier.
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.
> It is so primitive that it is unable to multiply integers. If you want to multiply, you have to write your own algorithm.
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.
I always thought multiplication was one of the most basic things a CPU should handle. Weren't computers invented to perform calculations? Even a pocket calculator could multiply. I assumed CPUs handled arithmetic and not much else. I didn't even learn about bit shifts until much later, and none of the programming languages I was taught ever introduced them.
You can ask your favourite LLM agent to give you an overview over earlier CPUs, including pocket calculators, with regards to multiplication. The x86 family of CPUs actually trace its lineage back to a desk calculator.
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.)
Not much later there was the Radio Shack Model 100, and a bit after that the Gateway portables, and of course, eventually the NEC Ultralite and eventually the Sharp PC-6220 (which was available under two other brands as well).
Also, for those with deep pockets there were the GRiD laptops....
My father was very much the embodiment of the late 80s businessman. In the 90s he gave me his (now outdated) Dolch lunchbox. I lugged it around alright. It ran DOS and iirc was a 286 processor.
Beat the heck out of dragging a 1702, a 1541 and a C64 around, though. I have three and they made regular trips to vintage fests because they were easy to set up. They can easily be connected to more drives or a bigger screen. Their only major drawback, and this is a big one, is that you can fry the SID if you plug in the external monitor with the power on. I did that once to my horror, and so have others.
A neighbor of mine had an Apple IIc when I was a kid and I thought it was the coolest, most futuristic computer I'd ever seen. I was very envious. So many colors.
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.
Love to see some aluminum frame parts introduced. Not cast aluminum parts—perhaps a machined aluminum deck and bezel. (There are of course places like PCBWay that will CNC metal parts for you.)
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.
Many of the cheap "educational toy laptops" which were somewhat common before "real" ones took over, also used a 6502-based SoC: https://github.com/davidgiven/vtech6502
Hey! Don't forget the French Micronique Hector HRX (1983) which had only Forth in ROM, and the MX (1985) which had both Forth and BASIC in ROM. They can both be emulated in MAME.
Most home computers from the 8bit era shipped with basic on the ROM, and people used it for memory mapped hardware access with peak and poke commands. It was basically the operating system for some of these computers.
A 6502 is capable of most actual workloads people have, whose profiles actually haven’t changed much. Almost all of our compute goes to GUI and rendering stacks that decorate our actual work.
The superpower of the PC over the previous generation was an order of magnitude more memory.
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.
Are segments really more flexible? I wrote some 8086 assembly back in the day, and they are a pain in the ass to work with. Code that spans segments has exactly the same problems bank switched systems have. I think the main benefit of segments is that only the CPU needs to worry about the segments, whereas with (most if not all?) bank switched systems, the whole computer sees banks being switched, which is a problem for DMA.
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.
Segment overrides were also painless to use, a single byte segment prefix byte was all that was needed to revector a memory operand to a different segment selector for the next instruction. With bank switching you'd have to use extra instructions and/or registers to switch the banking window to the desired bank and back, and possibly bounce to a routine in RAM to do that if you only had one banking window (which was quite common).
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.
I favor simpler machines, but that seems a bit of a stretch. Most people would like to communicate over the internet without every intermediate hop seeing their traffic (so, their emails, their chats, their credit card number, ...), therefore they want TLS which I don't think is practical on a 6502? To say nothing of watching videos and listening to music.
I'd compare to a z80 with 64k of memory, which would be enough to run CP/M. That wouldn't allow TLS, or music playback, but it would allow wordperfect, turbo pascal, a bunch of old C-compilers, and a spreadsheet or two.
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..
That's not entirely true. A quick search turned up a few projects, e.g. this one:
https://github.com/davidgiven/cpm65
(it's a port, so I would consider that to be 'native' rather than a 'remake')
I guess we can argue technicalities, but since the processor is different, and the 6502 handles the zero-page specially the end result is that you have to rebuild/recompile your binaries to run them under cpm65.
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.)
It's true that a computer can do everything, as long as you carve out exceptions for anything the computer can't do, but it seems like a rather pointless position. I feel quite comfortable saying that "most actual workloads people have" includes the functions once embodied by radio, TV, record/tape/CD players, and more.
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?
It's gotta be integrated together (and possibly be at a smaller process size) before you get all the power savings. If you have a real 6502, it has no internal RAM or cache, and you need to send power back and forth to the RAM chips. (I presume it's SRAM, but it could also be PSRAM)
If you ran a 6502 emulator on a cheap ARM SOC, it would be much lower power.
When you say "sleep mode", do you mean like Z80 having a HALT instruction which waits for an interrupt, or do you mean entering a very low power state like a laptop put to sleep?
6502 emulators can easily detect dumb endless loops, and that can turn into what's basically a Z80 HALT.
There used to be small IBM PC compatible "palmtop" computers capable of running for many days on a pair of AA batteries. HP 200LX was pretty cool. I think it had 80C186 running at 10 MHz or thereabouts, with 1MB of RAM, monochrome graphic LCD and PCMCIA cards for storage. Norton Commander and Turbo C run on it without any problems.
There was also the HP 95LX with a smaller screen (40x16, 240x128), a 5.37 MHz NEC V20 CPU, and 512K or 1MB of RAM.
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.
Can it run C64 games? If not, Hessian cold be ported to that. On Internet, once you get IRC you can connect to servers from Bitlbee. Gopher has gopher://magical.fish and Usenet it's surpisingly usable.
Also, Microchess from the Kim-1 could be ported in a weekend on that.
It’s Paula Maddox, who has for decades now done all kinds of wild and wonderful projects - she is a synthesizer designer, her works resulted in the Modal Electronics company and its line of synths, prior to that she had her own cottage synth product line. She also designed a full-scale working CPU out of chips, an excellent education project.
(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)
https://codeberg.org/TechPaula/LT6502b
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)
"Let's see if it looks cool. It's very important that it looks cool!"
Turns out it looks awesome. I wasn't expecting such a striking design.
Interesting spec. Why go for 48K of RAM and not at least 64K (the full address space without paging)?
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
Wouldn't this be because the ROM is taking up address space and they don't have bank switching? One of the future goals is to copy the ROM and RAM and switch it out of the address space.
That's how it was on the Spectrum, at least - it had 64k of RAM but the bottom 16K was permanently mapped to the ROM[0].
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...
This was exactly one of the many hardware projects that were published in the spanish magazine microhobby.
Long story short: it added 16K of RAM that was mapped at 0, and allowed both manual control with buttons or software control via a port to decide if it is mapped only for writes or it is mapped for both reads and writes.
https://microhobby.speccy.cz/mhf/103/MH103_20.jpg https://microhobby.speccy.cz/mhf/103/MH103_21.jpg https://microhobby.speccy.cz/mhf/103/MH103_22.jpg
https://microhobby.speccy.cz/mhf/104/MH104_22.jpg https://microhobby.speccy.cz/mhf/104/MH104_23.jpg https://microhobby.speccy.cz/mhf/104/MH104_24.jpg
My understanding was that Sinclare got to 48K using 8× 4116 + 8× 4532 chips where the 4532 was basically a 64K-bit 4164 where only half the chip worked.
> 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.
https://en.wikipedia.org/wiki/Sideways_address_space
It's a 25% cut on the cost of RAM!
I'm trying to figure out the video part, there is a demo screen that is showing pretty high res in color, and this says 1024x600 and 256 colours- that is mighty impressive for a 6502, that is driving way more pixels that I ever saw in that era, so I was expecting there was some other chip being used as a screen buffer and graphics chip...
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?
It seems based on previous entries that the display connector goes to a smart LCD controller, RA8889: https://www.maddox.pro/?p=429
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 wondered the same thing, and it looks like it uses this CMOS-compatible high level TFT driver: https://www.raio.com.tw/en/RA8889.html with a character generator, geometry primitives, etc.
> this says 1024x600 and 256 colours
> 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.
The modern WDC 65C02 is also way faster (up to 14MHz in the right conditions) than other 6502s of the era (usually 1-2MHz).
These sorts of project should be using the 68000 or the 65816 which both give a 24 bit address bus. Meaning they get 16 MB of address space to work with. They can make directly addressable frame buffers at high resolutions and reasonable color depths, and still have lots of memory available for programs and data.
At that point you may as well go for a RISC-V or ARM microcontroller.
I'm guessing that that is just the spec for the hardware, not what the machine can actually use.
Man it's been a while since I heard about EhBASIC.
Very interesting project. It'd be nice to see video of it in action and what use cases the author had in mind. A pic in a different post shows the 48k ram chip, and not far away is an SD card of 1 gigabyte - that's a dramatic contrast. The storage can hold the contents of ram 21,845 times over. If an 8GB laptop today had the equivalent storage, it would be a disk of 174TB.
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)
In the retro world we’ve already had the incongruent “64k RAM vs 8GB Storage” conundrum to deal with for decades.
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 ..
The goal is to make systems which AI cannot run on, yet still have value for simple compute tasks. Everything else is a cover for this truth.
Oh, it is very much a truth, I agree. The machine is the purpose - you can see it in all of her designs, which are very directed, intentionally, towards well-stated goals.
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.
The 6502 can't actually address more than that. The flash controller built into modern SD cards are also going to be significantly more powerful than the 6502. And I'm surprised you can even buy SD cards that small still!
> The 6502 can't actually address more than that.
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)
Quick note that bank switching does not in fact allow the CPU to "address" more than 64K. It allows the machine to "have" more than 64K but only 64K of it can be addressed by the CPU at any time.
The MOS 6509 has bank switching hardware built into the CPU, instead of being on an external MMU chip such as the MOS 8722.
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?
And could you imagine how painful it would be to manage megabytes of RAM with bank switching on a 6502!
Bank switching is how nearly all the major computers and consoles managed to address larger than 64k carts and memory.
The C64 actually had 64K of ram, 4k of devices (graphics, sound etc) and 16K of ROM.
A pic in a different post shows the 48k ram chip, and not far away is an SD card of 1 gigabyte - that's a dramatic contrast
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
> an 8-bit CPU at a few dozen MHz
The 80C51 is just never going away is it? I mean there's no reason for it to.
The 8051 is just about 'free' in the sense that all it's patents, etc., have expired. So anyone who says "I need to throw a bit of microcontroller at this problem" can either grab a sub-pennies device or throw a bit of no cost/low cost 8051 IP in a tiny corner of an FPGA or ASIC and leverage 50 something years of experience, tooling, examples, etc. It's not as cool as a ARM or RISC-V, but it serves a purpose.
That's a CompactFlash card. You often see them used in places where an IDE drive would have been.
The 6502 is so primitive that it runs on an Atari equipped with 128 bytes of RAM.
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.
I assume you're talking about the Atari 2600 console (VCS), which uses a limited version of that CPU, called 6507. It has the addressing space reduced to 16 KB.
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.
The very idea of "racing the beam" is madness distilled. How do you draw without a framebuffer and keep track of everything's position using just 128 bytes of RAM? This comment alone uses more RAM than that.
https://youtu.be/sJFnWZH5FXc
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
All the code is kept in the rom, as are all the assets. So you only need to track sprites that move unpredictably, and the average 2600 game had very few of those - pacman, space invaders, etc have very few actice objects, and most of them are strictly constrained in how they can move.
I don't know about Space Invaders, but Pac-Man on the 2600 used incredible hacks that were widely criticized, but essential to cramming the spirit of the game into that tiny cartridge and puny machine.
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.
It's the other way around - 2600 Pac-Man didn't do any hacks and that's what made it terrible.
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.
> 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.
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.
Recently they created a good homebrew port, miles ahead of the commercial release.
Graphics bitmap data was in the ROM - it was copied directly to the TIA's graphics or playfield data registers line by line by the CPU. No intermediate copy-to-RAM needed.
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.
The VCS has some handy features that makes it easier.
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.
> It is so primitive that it is unable to multiply integers. If you want to multiply, you have to write your own algorithm.
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.
It may be weird to say for you, but certainly not for an LLM!
Has the situation here really gotten so bad that no one can tell at a glance that they're responding to mindless LLM texts?
LLMs are usually better informed..
I always thought multiplication was one of the most basic things a CPU should handle. Weren't computers invented to perform calculations? Even a pocket calculator could multiply. I assumed CPUs handled arithmetic and not much else. I didn't even learn about bit shifts until much later, and none of the programming languages I was taught ever introduced them.
You can ask your favourite LLM agent to give you an overview over earlier CPUs, including pocket calculators, with regards to multiplication. The x86 family of CPUs actually trace its lineage back to a desk calculator.
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.)
The first CPUs were meant to power calculators.
You have much to learn.
Trying out different multiplication algorithms is a lot of fun.
https://github.com/TobyLobster/multiply_test
And yet a million programs were written and sold for it, and it became legendary, and begat a computer revolution.
It's so primitive that it can be understood.
Relevant fun:
https://monster6502.com/
https://skilldrick.github.io/easy6502/
Well, there was the Commodore SX 64. Not exactly lap sized but portable for sure.
https://de.wikipedia.org/wiki/Commodore_SX-64
Of course, is's great for executive poolside work, see also https://sm.pcmag.com/t/pcmag_uk/photo/c/commodore-/commodore...
Great find, it looks kinda silly now. But back then, they must've sold more than one.
While he's leaning forward peering at the tiny screen he's ideally placed to take a sip of that drink through the straw
Not much later there was the Radio Shack Model 100, and a bit after that the Gateway portables, and of course, eventually the NEC Ultralite and eventually the Sharp PC-6220 (which was available under two other brands as well).
Also, for those with deep pockets there were the GRiD laptops....
None of those are 6502-based, though. I think that's why OP referenced the SX-64.
Correct. I didn't mean to give the impression that CPU was common amongst them, rather just quickly sketching out form-factor evolution.
EDIT: mentioning the Apple IIc (and later IIgs) as was done else-thread would've been more on-topic.
My father was very much the embodiment of the late 80s businessman. In the 90s he gave me his (now outdated) Dolch lunchbox. I lugged it around alright. It ran DOS and iirc was a 286 processor.
https://en.wikipedia.org/wiki/Dolch
It weighed 23 pounds. It was approximately as portable as a tower PC. You could schlep one around, but it'd get heavy after a while.
Beat the heck out of dragging a 1702, a 1541 and a C64 around, though. I have three and they made regular trips to vintage fests because they were easy to set up. They can easily be connected to more drives or a bigger screen. Their only major drawback, and this is a big one, is that you can fry the SID if you plug in the external monitor with the power on. I did that once to my horror, and so have others.
I've only seen one in person and it was at one of the first The Gathering demo parties back in the 90's...
While not "portable" in the common modern sense, we also had:
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)
The SX-64, too: https://lunduke.locals.com/post/3337763/commodore-sx-64-the-...
Perfect for some poolside work.
A neighbor of mine had an Apple IIc when I was a kid and I thought it was the coolest, most futuristic computer I'd ever seen. I was very envious. So many colors.
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.
What an interesting layout for a mobile site. It had the archive and a bunch of other stuff before the post. I thought OP linked something wrong.
This is a cool project. The AI banner looks awful.
Yep. Nothing makes me lose interest in something faster than slop right at the top of the page...
Love to see some aluminum frame parts introduced. Not cast aluminum parts—perhaps a machined aluminum deck and bezel. (There are of course places like PCBWay that will CNC metal parts for you.)
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.
how much of the design is about making it usable today versus just seeing how far you can push the 6502. Either way, it's a fun project.
Many of the cheap "educational toy laptops" which were somewhat common before "real" ones took over, also used a 6502-based SoC: https://github.com/davidgiven/vtech6502
The Z80 has likewise experienced the same use: https://hackaday.io/project/166921-v-tech-genius-leader-prec...
There's gotta be some reason she's not using a 65c816 but I can't think of one
The goal of that machine is clearly not performance, she's probably just using a chip she's fond of
"Getting it to at least run BASIC" is a common theme with DIY enthusiasts. Why is that?
It's traditional:) The original machines with simpler hardware largely converged to BASIC, so it's a nice benchmark for "is this a Real Computer™"
Hardware didn't really play a factor.
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.
> If your machine didn't, it was weird.
Aha, step forward the Jupiter Ace...
Hey! Don't forget the French Micronique Hector HRX (1983) which had only Forth in ROM, and the MX (1985) which had both Forth and BASIC in ROM. They can both be emulated in MAME.
I've never seen one of those before! Easy to see where the Amstrad CPC464/Spectrum +2 got the design cues from though, eh?
A lot of machines based on this CPU booted a ROM that ran a BASIC. It seems more of a challenge than running a Forth.
Most home computers from the 8bit era shipped with basic on the ROM, and people used it for memory mapped hardware access with peak and poke commands. It was basically the operating system for some of these computers.
A 6502 is capable of most actual workloads people have, whose profiles actually haven’t changed much. Almost all of our compute goes to GUI and rendering stacks that decorate our actual work.
My first job was writing barcode printing software for the Apple II. One of my last jobs 42 years later was also related to printing barcodes.
It sometimes seems that all we have done over that period is add layers and layers of complexity.
The superpower of the PC over the previous generation was an order of magnitude more memory.
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.
Are segments really more flexible? I wrote some 8086 assembly back in the day, and they are a pain in the ass to work with. Code that spans segments has exactly the same problems bank switched systems have. I think the main benefit of segments is that only the CPU needs to worry about the segments, whereas with (most if not all?) bank switched systems, the whole computer sees banks being switched, which is a problem for DMA.
Oh, absolutely.
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.
Segment overrides were also painless to use, a single byte segment prefix byte was all that was needed to revector a memory operand to a different segment selector for the next instruction. With bank switching you'd have to use extra instructions and/or registers to switch the banking window to the desired bank and back, and possibly bounce to a routine in RAM to do that if you only had one banking window (which was quite common).
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.
I favor simpler machines, but that seems a bit of a stretch. Most people would like to communicate over the internet without every intermediate hop seeing their traffic (so, their emails, their chats, their credit card number, ...), therefore they want TLS which I don't think is practical on a 6502? To say nothing of watching videos and listening to music.
I'd compare to a z80 with 64k of memory, which would be enough to run CP/M. That wouldn't allow TLS, or music playback, but it would allow wordperfect, turbo pascal, a bunch of old C-compilers, and a spreadsheet or two.
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..
That's not entirely true. A quick search turned up a few projects, e.g. this one: https://github.com/davidgiven/cpm65 (it's a port, so I would consider that to be 'native' rather than a 'remake')
I guess we can argue technicalities, but since the processor is different, and the 6502 handles the zero-page specially the end result is that you have to rebuild/recompile your binaries to run them under cpm65.
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.)
>or music playback
We had record players for that, and Walkmans for when we were out and about.
It's true that a computer can do everything, as long as you carve out exceptions for anything the computer can't do, but it seems like a rather pointless position. I feel quite comfortable saying that "most actual workloads people have" includes the functions once embodied by radio, TV, record/tape/CD players, and more.
> 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.
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.
Those people you speak of, how big are their numbers all in all you think? And is that a subgroup of a subgroup?
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.
Zoom calls?
Maybe Bullshit Jobs was onto something, it seems that my entire work day consists of work decoration.
Here is what I get confused about...
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?
It's gotta be integrated together (and possibly be at a smaller process size) before you get all the power savings. If you have a real 6502, it has no internal RAM or cache, and you need to send power back and forth to the RAM chips. (I presume it's SRAM, but it could also be PSRAM)
If you ran a 6502 emulator on a cheap ARM SOC, it would be much lower power.
There was no sleep mode on the 6502 so even an emulator would need to be running continuously.
When you say "sleep mode", do you mean like Z80 having a HALT instruction which waits for an interrupt, or do you mean entering a very low power state like a laptop put to sleep?
6502 emulators can easily detect dumb endless loops, and that can turn into what's basically a Z80 HALT.
Nitpick, the laptop mentioned is actually using a 65C02 which does have STP (stop clock) and WAI (wait for interrupt) instructions.
There used to be small IBM PC compatible "palmtop" computers capable of running for many days on a pair of AA batteries. HP 200LX was pretty cool. I think it had 80C186 running at 10 MHz or thereabouts, with 1MB of RAM, monochrome graphic LCD and PCMCIA cards for storage. Norton Commander and Turbo C run on it without any problems.
There was also the HP 95LX with a smaller screen (40x16, 240x128), a 5.37 MHz NEC V20 CPU, and 512K or 1MB of RAM.
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.
Atari Portfolio says hi.
The display also takes power, quite a lot actually - 2-5W
Can it run C64 games? If not, Hessian cold be ported to that. On Internet, once you get IRC you can connect to servers from Bitlbee. Gopher has gopher://magical.fish and Usenet it's surpisingly usable.
Also, Microchess from the Kim-1 could be ported in a weekend on that.
When I saw the domain name, I thought this might be:
https://basharchive.org/#s/Maddox
It’s Paula Maddox, who has for decades now done all kinds of wild and wonderful projects - she is a synthesizer designer, her works resulted in the Modal Electronics company and its line of synths, prior to that she had her own cottage synth product line. She also designed a full-scale working CPU out of chips, an excellent education project.
(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)
it was very respectable until i read "Better sound chip, the SID is ok, but it’s a bit limited by modern standards."
sheesh.
[flagged]
[dead]
[flagged]
[flagged]
It’s not a laptop! It’s just a desktop in a ugly fat laptop-ishy case.