Watford Electronics Eureka 64K
Watford Electronics Eureka 64K
Thanks to CfCH and dumped at the virtual ABUG.
http://www.computinghistory.org.uk/det/ ... ureka-64K/
- Attachments
-
- Eureka64K.zip
- (4.98 KiB) Downloaded 72 times
- Nigel
BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.
BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.
Re: Watford Electronics Eureka 64K
I never noticed tbis back in the day (or even up until today when looking in a AcornUser Nov 86):
Was it too late to be successful?
Are their any reviews of it?
Most importantly, how does it work?
Was it too late to be successful?
Are their any reviews of it?
Most importantly, how does it work?
Re: Watford Electronics Eureka 64K
It's been a few years since I looked at it but didn't have much success working out how the board works unfortunately.
- Nigel
BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.
BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.
Re: Watford Electronics Eureka 64K
Ooh this sounds a lot like my SuperShadow system - more details would be great if anyone has them!
Re: Watford Electronics Eureka 64K
The manual is here: I am reading it
http://8bs.com/othrdnld/manuals/hardwarebbcseries.shtml
It seems the extra memory is for data (Basic code/vars or compatible sideways rom app data): it seems to make a modified copy of the current 'language/app' in its own sideways ram and runs that instead, but this seems to limit it to roms supported by its utility rom, which holds the necessary changes for supported apps. But you get more data space than on a 64k 6502 2ndp or gfoots Supershadow which loses 16k to running a hicopy of said app hence the Eureka's 58 for basic programmes or wordprocessor/spreadsheet documents..
Its still surprising it seems so under the radar: maybe its the sort of thing that needs the weight of the original manufacturer to say here is a standard..?
Last edited by B3_B3_B3 on Wed Dec 13, 2023 7:45 pm, edited 1 time in total.
Re: Watford Electronics Eureka 64K
Ah I see, yes something like that would be necessary to get that much memory to work.
I wondered whether they somehow observed that BASIC only uses certain instructions to access the user program, data, etc, and never uses those instructions to access its own ROM, so they'd then be able to do some trickery with shadow-like switching for each cycle - like on the Master - to redirect just those cycles to access different banks. For example, I can imagine that all access to the user program and data (PAGE to HIMEM) would occur through indirect addressing, and perhaps all accesses to the BASIC ROM itself and to page zero would occur through ablosute addressing - so you could easily redirect user program/data access to a different RAM bank. But there are some grey areas like the BASIC workspace, which are probably accessed with a mixture of the two, so then there may be more to it than that. Perhaps you can get away with redirecting indirect memory operations to the shadow memory for addresses above &800 and leaving them in normal Beeb memory for addresses below that - and of course only do this for code running from sideways ROM.
Anything like that is going to depend a bit on what that software does and perhaps whether their device has specific support for that software.
I wondered whether they somehow observed that BASIC only uses certain instructions to access the user program, data, etc, and never uses those instructions to access its own ROM, so they'd then be able to do some trickery with shadow-like switching for each cycle - like on the Master - to redirect just those cycles to access different banks. For example, I can imagine that all access to the user program and data (PAGE to HIMEM) would occur through indirect addressing, and perhaps all accesses to the BASIC ROM itself and to page zero would occur through ablosute addressing - so you could easily redirect user program/data access to a different RAM bank. But there are some grey areas like the BASIC workspace, which are probably accessed with a mixture of the two, so then there may be more to it than that. Perhaps you can get away with redirecting indirect memory operations to the shadow memory for addresses above &800 and leaving them in normal Beeb memory for addresses below that - and of course only do this for code running from sideways ROM.
Anything like that is going to depend a bit on what that software does and perhaps whether their device has specific support for that software.