Precompiled Overlays???
Christof Eb.
Posts: 1,590
Hi,
as we are all running short of RAM sooner or later, I wanted to start some discussion about precompiled overlays. Idea is instead of holding everything in RAM all the time, have the machine quickly load a chunk of stuff from SD card. For example an editor or an assembler does not need to be in RAM all the time.
So far I have found one resource about this: https://www.forth.org/fd/FD-V05N1.pdf
Do you know other implementations? Ideas, comments, suggestions?
Christof
Comments
A RAM expansion is even faster than SD card for such a use. SD card can still be the file store but loading everything into extended RAM at power up will allow for much smoother runtime operation.
I presume Ada's game emulators are done alone these lines. She has mentioned it only functions as a ROM replacement - Which is similar nature to overlaying. This will be because when the content is read-only it can be reliably fetched in contiguous bursts and it doesn't really matter if only one byte is needed. The remainder can hang around or be tossed.
Writes are difficult because optimising for tiny writes is way different to contiguous bursts. So then that leads to having to do checks, which are always cumbersome.
Catalina supports overlays for both the Propeller 1 and Propeller 2. See the section Using Catapult with Overlay Files in the document Getting Started with Catapult and the examples in demos/catapult/over_p1.c (Propeller 1) or demos/catapult/over_p2.c (Propeller 2).
However, this seems to be broken the current release!
I'll find out why and fix.
EDIT: It does work - I was just being silly and copying the wrong files to the SD card!
Ross.
@"Christof Eb."
I've amended my previous post. Catalina's overlays do work with the current release. Turned out I was not copying the files to the SD card correctly.
I need to add a warning if the program can't find its overlay files - at the moment it just fails silently.
Ross.
Are we, really? The P1 limit of only 32kB was really painful. But I've never been running out of RAM on the P2, so far. The original Amiga 1000 had only 256kB of RAM and it had a multitasking OS and GUI. Yes, compared to the desktop PCs of theese days we are a bit spoiled when it comes to resolution and color depth. But I think although it's not impossible the P2 is not the ideal platform to build a stand-alone computer. It's better suited for peripheral devices and embedded applications. And if you really need a GUI that has a larger screen than an oscilloscope or a 3D printer than I would use some RasPi as frontend and the P2 as control/communication and analogue back end, only.
I have to admit that there are cases where you wand and need external RAM. The P2 is good at emulation special hardware like old game consoles. The work of @Wuerfel_21 is really outstanding and there it makes perfect sense to use external RAM and overlays. And for games it's also perfectly OK to play one level, wait some seconds for the next level to load and then move on... However, for a office or workbench application I wouldn't want it that way and for real time applications like machine control it's an absolute show-stopper.
Loading data on the fly from external storage is easy. But do you really need code overlays?
The console emulators are actually hard real-time applications! No overlays! Neo Geo games in particular are written with the assumption that there are up to 64MB of mask ROMs directly connected to the video bus, so they don't really load anything in advance, ever. The (to us totally opaque) game code just determines "I want this tile to appear here" and it can grab that tile from anywhere in the huge ROM. My NeoYume rendering code works with a 2-line buffer in sync with the video driver, so there's a ~63 microsecond deadline to fetch all the 16x1 tile slivers needed for a given scanline (max. 96 of them) from PSRAM in between computing their addresses and having to actually blit them into the buffer. At the same time the 68000 core can also access it's code ROM (which is very latency sensitive) and the ADPCM sound streaming is going on, so constant small accesses from all these sources need to be interleaved and handled. And it works out just fine.
That said, if you did use code overlays stored in PSRAM, they also would switch in 1-2 milliseconds due to high bulk transfer bandwidth, which for a UI application is well below a single screen refresh.
Sorry for the confusion. What I actually meant is that your console emulators are a good example where external memory is justified as opposed to my own work where I haven't needed it, so far. And games from the 80s and 90s are good examples for the use of overlays. That are of course two completely different things, except for the fact that probably some of those games run on the emulator.
I still wonder why @"Christof Eb." wants code overlays. Especially, forth is so compact that it would need years of coding until you hit the 512kB barrier.