"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.
mk_stjames 10 hours ago [-]
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?
boomlinde 2 hours ago [-]
It seems based on previous entries that the display connector goes to a smart LCD controller, RA8889: https://www.maddox.pro/?p=429
> 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.
Someone 3 hours ago [-]
> 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.
dannyobrien 8 hours ago [-]
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.
cbm-vic-20 3 hours ago [-]
The modern WDC 65C02 is also way faster (up to 14MHz in the right conditions) than other 6502s of the era (usually 1-2MHz).
wang_li 57 minutes ago [-]
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.
forinti 5 hours ago [-]
I'm guessing that that is just the spec for the hardware, not what the machine can actually use.
Lio 7 hours ago [-]
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
yoavm 16 minutes ago [-]
It's a 25% cut on the cost of RAM!
xioxox 7 hours ago [-]
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.
zimpenfish 7 hours ago [-]
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.
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.
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.
t0mek 6 hours ago [-]
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.
bugake 6 hours ago [-]
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
RiverCrochet 2 hours ago [-]
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.
boomlinde 49 minutes ago [-]
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.
creshal 5 hours ago [-]
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.
ButlerianJihad 5 hours ago [-]
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.
vikingerik 3 hours ago [-]
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.
anthk 4 hours ago [-]
Recently they created a good homebrew port, miles ahead of the commercial release.
eru 6 hours ago [-]
> 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.
NotCamelCase 5 hours ago [-]
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?
bugake 6 hours ago [-]
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.
eru 5 hours ago [-]
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.)
dboreham 1 hours ago [-]
You have much to learn.
forinti 3 hours ago [-]
Trying out different multiplication algorithms is a lot of fun.
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)
MomsAVoxell 10 hours ago [-]
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 ..
userbinator 10 hours ago [-]
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
ErroneousBosh 9 hours ago [-]
> 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.
Rohansi 15 hours ago [-]
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!
skissane 14 hours ago [-]
> 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)
dboreham 1 hours ago [-]
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.
MiroslavPokorny 9 hours ago [-]
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.
doubled112 14 hours ago [-]
That's a CompactFlash card. You often see them used in places where an IDE drive would have been.
notorandit 10 hours ago [-]
While not "portable" in the common modern sense, we also had:
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.
JKCalhoun 3 hours ago [-]
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.
weinzierl 16 hours ago [-]
Well, there was the Commodore SX 64. Not exactly lap sized but portable for sure.
While he's leaning forward peering at the tiny screen he's ideally placed to take a sip of that drink through the straw
bartvk 10 hours ago [-]
Great find, it looks kinda silly now. But back then, they must've sold more than one.
d1l 5 hours ago [-]
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.
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....
classichasclass 13 hours ago [-]
None of those are 6502-based, though. I think that's why OP referenced the SX-64.
WillAdams 5 hours ago [-]
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.
kstrauser 15 hours ago [-]
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.
classichasclass 14 hours ago [-]
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.
vidarh 8 hours ago [-]
I've only seen one in person and it was at one of the first The Gathering demo parties back in the 90's...
discardable_dan 14 hours ago [-]
This is a cool project. The AI banner looks awful.
uv-depression 2 hours ago [-]
Yep. Nothing makes me lose interest in something faster than slop right at the top of the page...
Neywiny 15 hours ago [-]
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.
Smith-7831 6 hours ago [-]
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.
makach 44 minutes ago [-]
it was very respectable until i read "Better sound chip, the SID is ok, but it’s a bit limited by modern standards."
sheesh.
userbinator 10 hours ago [-]
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
There's gotta be some reason she's not using a 65c816 but I can't think of one
ura_yukimitsu 8 hours ago [-]
The goal of that machine is clearly not performance, she's probably just using a chip she's fond of
4 days ago [-]
burner420042 14 hours ago [-]
"Getting it to at least run BASIC" is a common theme with DIY enthusiasts. Why is that?
yjftsjthsd-h 13 hours ago [-]
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™"
reaperducer 13 hours ago [-]
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.
ErroneousBosh 9 hours ago [-]
> If your machine didn't, it was weird.
Aha, step forward the Jupiter Ace...
MobiusHorizons 2 hours ago [-]
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.
pigeons 13 hours ago [-]
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.
user3939382 15 hours ago [-]
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.
tonyedgecombe 9 hours ago [-]
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.
whartung 12 hours ago [-]
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.
gsliepen 8 hours ago [-]
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.
whartung 21 minutes ago [-]
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.
yjftsjthsd-h 13 hours ago [-]
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.
stevekemp 13 hours ago [-]
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..
ochrist 9 hours ago [-]
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')
stevekemp 4 hours ago [-]
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.)
tonyedgecombe 9 hours ago [-]
>or music playback
We had record players for that, and Walkmans for when we were out and about.
yjftsjthsd-h 43 minutes ago [-]
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.
ErroneousBosh 9 hours ago [-]
> 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.
lukan 15 hours ago [-]
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.
Grombobulous 13 hours ago [-]
Zoom calls?
Maybe Bullshit Jobs was onto something, it seems that my entire work day consists of work decoration.
anthk 4 hours ago [-]
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.
system7rocks 14 hours ago [-]
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?
Dwedit 14 hours ago [-]
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.
tonyedgecombe 8 hours ago [-]
There was no sleep mode on the 6502 so even an emulator would need to be running continuously.
Dwedit 2 hours ago [-]
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.
generuso 12 hours ago [-]
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.
MomsAVoxell 1 hours ago [-]
Atari Portfolio says hi.
oofbaroomf 14 hours ago [-]
The display also takes power, quite a lot actually - 2-5W
debo_ 15 hours ago [-]
When I saw the domain name, I thought this might be:
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)
learntoplaypitc 2 hours ago [-]
[flagged]
utopcell 14 hours ago [-]
[dead]
bozdemir 9 hours ago [-]
[flagged]
levicanskij 9 hours ago [-]
[flagged]
fatbitch 11 hours ago [-]
It’s not a laptop! It’s just a desktop in a ugly fat laptop-ishy case.
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.
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.
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
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.
https://en.wikipedia.org/wiki/Sideways_address_space
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.
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.
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.
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.
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.
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?
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.)
https://github.com/TobyLobster/multiply_test
It's so primitive that it can be understood.
Relevant fun:
https://monster6502.com/
https://skilldrick.github.io/easy6502/
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)
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 ..
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.
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.
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.
https://de.wikipedia.org/wiki/Commodore_SX-64
https://en.wikipedia.org/wiki/Dolch
Also, for those with deep pockets there were the GRiD laptops....
EDIT: mentioning the Apple IIc (and later IIgs) as was done else-thread would've been more on-topic.
sheesh.
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.
Aha, step forward the Jupiter Ace...
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.
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.
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..
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.
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.
Also, Microchess from the Kim-1 could be ported in a weekend on that.
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.
6502 emulators can easily detect dumb endless loops, and that can turn into what's basically a Z80 HALT.
https://basharchive.org/#s/Maddox
(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)