Page 1 of 2
GeoRAM on the Vic20
Posted: Sun Nov 26, 2017 6:31 pm
by CurtisP
Hey guys, I'm back.
Anyway, I somehow got obsessed with the idea of using GeoRAM on the Vic20 using the Masc=uerade adapter, since this configuration is supported by VICE.
Anyway, here are the relevant memory locations:
40959 - $9fff - block selection, each block is 16KB
40958 - $9ffe - select a 256-byte page within the block (0-63)
38912 - $9800 - GeoRAM page access
Re: GeoRAM on the Vic20
Posted: Sun Nov 26, 2017 7:15 pm
by eslapion
GeoRAM is a large bunch of 256 bytes pages. On the VIC-20, the IO areas are 1024 bytes which can reduce swapping.
Plugging a GeoRAM on a VIC-20 is really trivial but it's not obvious to me that's it is really useful.
On the C64, reserving a 8k area either reduces the amount of RAM available to basic or requires disabling some of the firmware ROMs. On the VIC-20, you can use BLK5 and use a very large RAM expansion based on 8k blocks instead of small 256 bytes pages.
It's easy to convert a Behr-Bonz board into a 128x8k (1024k) RAM expansion. Perhaps even a 128x32k (4MBytes) expansion if you're willing to 'window' BLK 1, 2, 3 and 5.
Re: GeoRAM on the Vic20
Posted: Mon Dec 04, 2017 10:10 pm
by CurtisP
The I/O areas on the C64 are also 1KB. The GeoRAM design put the 256 byte page at the bottom of the 1k and the two control registers at the top, wasting a lot of space.
Of course it was not really meant for direct memory access, but for memory swapping.
I'm a bit dubious about the VICE implementation, since seems to be mapping three GeoRAM across both I/O slots.
Re: GeoRAM on the Vic20
Posted: Tue Dec 05, 2017 4:51 am
by MCes
Re: GeoRAM on the Vic20
Posted: Tue Dec 05, 2017 5:11 am
by Mike
CurtisP wrote:The I/O areas on the C64 are also 1KB.
Erm, no. The I/O address range on the C64 is partitioned as follows:
Code: Select all
$D000..$D3FF: VIC
$D400..$D7FF: SID
$D800..$DBFF: colour RAM
$DC00..$DCFF: CIA #1
$DD00..$DDFF: CIA #2
$DE00..$DEFF: I/O 1 for cartridge port, 256 bytes
$DF00..$DFFF: I/O 2 for cartridge port, 256 bytes
The address ranges for VIC, SID, CIA #1 and CIA #2 contain a lot of mirrors due to incomplete address decoding.
Re: GeoRAM on the Vic20
Posted: Tue Dec 05, 2017 6:14 am
by groepaz
I'm a bit dubious about the VICE implementation, since seems to be mapping three GeoRAM across both I/O slots.
three? how three? *shrug*
it maps the registers into the IO2 area (dffe/ff - with mirrors across the whole page due to incomplete decoding) and the actual RAM page into IO1 (dexx). nothing dubious about it really
and no, the big advantage of georam over REU is that you can do direct memory access (and even run code in the mapped RAM). and most programs use it that way, just copying stuff in and out would be a waste of time.
Re: GeoRAM on the Vic20
Posted: Wed Dec 13, 2017 11:16 pm
by CurtisP
So the GeoRAM basically took up both I/O blocks on the C64, then. I need to look at three memory maps again. It seems I'm not as good at mental hexadecimal as I used to be.
Also, I was fairly certain that Geos used the GeoRAM for swapping. I don't know how many other programs supported it.
Re: GeoRAM on the Vic20
Posted: Sun Feb 25, 2018 9:40 pm
by brain
I'd be interested if you get it working. The GeoRAM was pretty simplistic.
Re: GeoRAM on the Vic20
Posted: Wed Feb 28, 2018 1:22 pm
by merman
brain wrote:I'd be interested if you get it working. The GeoRAM was pretty simplistic.
Yeah, it lacked the DMA chip that was in official Commodore REUs so transfer speeds were slower.
Re: GeoRAM on the Vic20
Posted: Wed Feb 28, 2018 1:40 pm
by Mike
To say GeoRAM "lacked" the DMA chip is possibly a bit of mis-nomer. It used another concept than the REUs.
With GeoRAM, contrary to the CBM REU, you can execute code in the (allegedly very small) 256 byte window banked into $DE00..$DEFF. As with all banking solutions, the contents of $DE00..$DEFF are changed by a single write to the control register. The REU would need 256 cycles to transfer that data.
Of course, if you then needed to copy the data in $DE00..$DEFF to another place, that'd require a copy loop on the CPU. Slower, but no showstopper. Both solutions provide extra memory, that is usable in one way or another.
Re: GeoRAM on the Vic20
Posted: Wed Feb 28, 2018 10:33 pm
by Gyro Gearloose
Mike wrote:To say GeoRAM "lacked" the DMA chip is possibly a bit of mis-nomer. It used another concept than the REUs.
With GeoRAM, contrary to the CBM REU, you can execute code in the (allegedly very small) 256 byte window banked into $DE00..$DEFF. As with all banking solutions, the contents of $DE00..$DEFF are changed by a single write to the control register. The REU would need 256 cycles to transfer that data.
Of course, if you then needed to copy the data in $DE00..$DEFF to another place, that'd require a copy loop on the CPU. Slower, but no showstopper. Both solutions provide extra memory, that is usable in one way or another.
Re: GeoRAM on the Vic20
Posted: Thu Mar 01, 2018 12:11 am
by Mike
Gyro Gearloose wrote:
Thanks. It took me some time though to spot the emphasis you added within the full quote.
Take that word, replace it with "admittedly" and you're there.
Re: GeoRAM on the Vic20
Posted: Thu Mar 01, 2018 11:49 am
by groepaz
btw, if you are curious to see software that runs entirely in such 256byte window - check the ISEPIC software. the cartridge works pretty similar regarding RAM mapping - only the bank switching is a lot more weird =)
Re: GeoRAM on the Vic20
Posted: Thu Mar 01, 2018 11:56 am
by brain
At the risk of shamelessly plugging my stuff, Ultimem has 1MB of SRAM, and it pages it in at 8kB chunks, so it may be much more usable than GeoRAM, and the device is supported in VICE as well.
Jim
Re: GeoRAM on the Vic20
Posted: Thu Mar 01, 2018 12:29 pm
by Mike
groepaz wrote:btw, if you are curious to see software that runs entirely in such 256byte window [...]
They surely have to map in a new 256-byte window whenever there is another sub-routine call. Including a small call stub that's present in all of these pages. I can vividly imagine that.
The address range of $9200..$93FF internal to VIC-20 could be used to pull off a similar stunt.
