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.
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)