GEOS

[ytm]

Hi

Encouraged by silverdr I started development of BeamRacer-compatible GEOS.

You can find it here on GitHub: https://github.com/ytmytm/geos/tree/beamracer-ramexp (make sure to checkout breamracer-ramexp branch).

Right now there is support for the same basic additional features that already existed in this reverse engineered GEOS back in 2000 for expansions like +60K and RamCart 64/128

• whole DeskTop will be cached in RAM, so you only need to keep it on the boot disk
  
• swap file for memory overwritten by running Desk Accessories (Calculator, Notepad, etc.) is stored in extra RAM rather than on the disk
  

This occupies most of the first 64K, so there are 7 banks left.

I plan to use 6x64K banks for disk cache / RAM disk.

The last bank would be reserved for the most ambitious project - redirecting all graphical functions of GEOS to BeamRacer, basically overlaying whole screen with Bitmap Sequencer data. This would allow to use step/repeat/copy features for fast access. VDC (80 column) support on C128 proves that this is possible to do and GEOS isolates applications from accessing bitmaps directly.

You can find whole roadmap here: https://github.com/ytmytm/geos/projects/1

There are no releases yet, but I have setup automated build already. If you go into Actions, then click on the latest CI workflow run, then in the Artifacts section you will find the PRG file that you can load and run. A disk with DeskTop must be in the drive 8.

[silverdr]

Boy - did I mention how glad am I to see you on board?! :-)))

[ytm]

Here is something that actually works in two drive setting. It only uses extra RAM to make things go faster:

- DeskTop is permanently cached, no need to keep it on every floppy
- there is no more time wasted on creating Swap File when running Desk Accessories
- Drive #8 is hardcoded as a 1541 with Shadow RAM (disk cache)
- custom CONFIGURE detects drive #9; it has original 1541 driver replaced by my patched version; it won't work if you have two different drive types (i.e. 1571 as #8 and 1541 as #9)

I didn't setup releases on GitHub yet, so D64 is attached here
  geos-beamracer-ramexp-0ce50462ef2971419b064bb2e0456aba0e7fd988.zip (Size: 48.19 KB / Downloads: 1) .

This was assembled from commit https://github.com/ytmytm/geos/commit/0c...ba0e7fd988

[ytm]

Here is a little update from a branch where I replace GEOS gfx routines by Beamracer and overlay whole screen using BR Programmable Bitmap Sequencer.

If you want to try this right away, here is the boot disk, compiled from beamracer-gfx branch head: 
  geos-beamracer-gfx-756a8cd2cdf7b5e0b245f0fdd4061f052aabee2e.zip (Size: 101.99 KB / Downloads: 5)
Note that it won't work in Kernal64 emulator because both DLs and bank switching are used.

Everything except strings draws to Beamracer RAM. Both ports are used - either to write into fore/backbuffer simultaneously or to use one to read and other to write data in read-modify-write setup. For line fill REP0/1 registers provide hardware acceleration.

All features provided by RAM expansion (DeskTop bufffer, drive 8 RAM shadowing) are enabled.

DeskTop runs fine. For debug purposes the display list and bitmap sequencer are enabled only for the top half of the screen.
   

GeoFont looks fine here but once font is loaded for editing one can see that the app writes directly to VIC bitmap at $a000-$bf40, so it will never work properly. Unfortunately most of GEOS 64 programs work this way, even main BSW apps like geoPaint.

   

Here in IconEdit split screen one can see what was stored in VIC bitmap directly, without referring to GEOS KERNAL:

   

Finally menus will look wrong sometimes because I have a strange off-by-one error somewhere:

   

Anyway, this is for fun. I think I will continue with this for a while just to have string drawing routines ready but it's clear that it will never be compatible with main GEOS 64 apps. It will be a good basis for hardware-accelerated TGI driver for CC65.

I will turn my focus to RAM expansion instead. Some of this work, especially with memory management, might be useful anyway.

[abbruzze]

Here is a little update from a branch where I replace GEOS gfx routines by Beamracer and overlay whole screen using BR Programmable Bitmap Sequencer.

If you want to try this right away, here is the boot disk, compiled from beamracer-gfx branch head: 
Note that it won't work in Kernal64 emulator because both DLs and bank switching are used.

Everything except strings draws to Beamracer RAM. Both ports are used - either to write into fore/backbuffer simultaneously or to use one to read and other to write data in read-modify-write setup. For line fill REP0/1 registers provide hardware acceleration.

All features provided by RAM expansion (DeskTop bufffer, drive 8 RAM shadowing) are enabled.

DeskTop runs fine. For debug purposes the display list and bitmap sequencer are enabled only for the top half of the screen.


GeoFont looks fine here but once font is loaded for editing one can see that the app writes directly to VIC bitmap at $a000-$bf40, so it will never work properly. Unfortunately most of GEOS 64 programs work this way, even main BSW apps like geoPaint.



Here in IconEdit split screen one can see what was stored in VIC bitmap directly, without referring to GEOS KERNAL:



Finally menus will look wrong sometimes because I have a strange off-by-one error somewhere:



Anyway, this is for fun. I think I will continue with this for a while just to have string drawing routines ready but it's clear that it will never be compatible with main GEOS 64 apps. It will be a good basis for hardware-accelerated TGI driver for CC65.

I will turn my focus to RAM expansion instead. Some of this work, especially with memory management, might be useful anyway.

Hi,
I fixed the DL2 logic accordingly with "Please note that there was an error in "VASYL registers" documenation - the trigger bit is NOT the MSB. It is bit #3" as reported by silverdr.
I tried to run your last .d64: the emulator crashes when you write (within a MOV) into register 0x52 that, as far as I know, doesn't exist.
I modified the code in order to ignore writings to non existing registers but at the end I got a JAM and the emulator stops to run.
I don't know if the JAM is caused by ignoring writings to 0x52. 

Any ideas ?

[laubzega]

Hey, thanks for posting this. It's nice to see VASYL getting some serious workout.

The disk worked for me with an NTSC VIC, but on PAL it only gets to the point where screen gets cleared, and then hangs. It was with JiffyDOS and SD2IEC, FWIW.

As a relative newcomer to the C64 I lack familiarity with GEOS, so it's difficult for me to assess the degree of speedup. Is there an equally convenient archive available featuring the regular version that I could just plug and run?

Thanks!

[silverdr]

An unprepared SD2IEC may expose problem booting GEOS. I didn't try on NTSC but on PAL I had to resort to Pi1541. It doesn't have to be this one though. Any device properly emulating 1541 at low level (like U1541 for example) should do.

[ytm]

Hi guys, I'm sorry for this very late answer, I simply forgot to subscribe to this thread.

Regarding SD2IEC problem - I don't know where the problem is. The assembled D64 image uses original 1541 disk driver, which SD2IEC should be able to detect and emulate the speeder. I'm using Ultimate 1541-II myself and this works fine.
I should check if Jiffydos may be the issue here.

In any case, I think I will add a "DOS" disk driver for GEOS that uses only B-R/B-W commands and Kernal I/O functions.

The drawing speedup is noticeable: most of the savings (both memory and CPU cycles) comes from the benefit of having REP, but also due to STEP automatically adjusting the address of the next byte. GEOS draws on two screens at once, so once we have the starting point and STEP we save a lot on not adjusting two 16-bit pointers on zero page.

@abbruzze One thing that I noticed is that in Kernal64 code both display list program and port data are fetched from the same "mem" pointer. This "mem" is updated according to currentBank right after a write to control register $31. But it doesn't work this way on the real hardware because once I setup display list in one bank I can change banks: read and write from C64 side all over the whole BeamRacer memory without stopping DL.