bsw128: Berkeley Softworks GEOS 128 2.0 variant, i.e. GEOS for C128 with 128 KB RAM and VDC 640px width support. This needs some more work to actually boot.

[xlar54]

What else is needed to make this boot? The docs dont say.

[rhalkyard]

I've been poking around at this and think I've got it working; check out the bootable-bsw128 branch in my fork of the repo.

Long story short, I:

• Used exomizer to build a RUN-able compressed kernal image (instead of pucrunch, which doesn't support the 128)
• Adjusted linker config for input drivers to use $FD00 base address (for simplicity's sake, I consolidated all the input drivers into the same segment, so there could just be a Geos64 linker config and a Geos128 one, rather than duplicating all of them)
• Inserted the selected input driver into combined kernal binary at $FD00

I've also added some logic that builds a bootable disk from the cbmfiles.com GEOS128.D64 disk image, matching the process of the the C64 variant.

I'll tidy things up a bit and make a PR at some point, but I thought I'd put it out there in its current state.

[mist64]

Awesome!

I have trouble reproducing it though. :( In VICE, it makes it up to the GEOS background pattern. Then, I am getting a JAM in the drive (with a 1571), or a hang (with a 1541).

• Built on Mac OS X 10.14.4.
• cc65 V2.15
• Exomize v2.0.9
• GEOS128.D64 is in the root directory, md5 2bd8dad9b98f969c6c93ce3448c03631.

[rhalkyard]

Ah, oops. Forgot that I'd only tested it with DRIVE=drv1571 and an emulated system with a 1571. In that case, it works fine, but with the 1541 driver, I see the same behavior as you. (with the 1571 driver, on a system with a 1541, I get a JAM too).

I wonder if it's something to do with the 128 kernal's disk driver swapping. Maybe the 1571 driver needs to be in place at startup, with the 1541 driver loaded in the other bank. I'll have a poke around and see.

[mist64]

It works for me with the 1571 driver. Excellent!

Maybe the 1541 driver is also different between GEOS64 and GEOS128...

[ytmytm]

There is one difference that has potential to make 1541/71 driver from GEOS 64 to crash in GEOS 128. There is one more byte popped from stack in IRQ handler on C128.

See here: https://github.com/ytmytm/c64-GEOS128/blob/master/drv1541.tas#L520

This is called through irqvec at $0314 when C128 Kernal handles interrupts.

[xlar54]

Is this the command you guys are using?:

make VARIANT=bsw128 DRIVE=1571 INPUT=mse1531

I get:

ca65 -D bsw128=1 -D 1571=1 -D mse1531=1 -I inc -I . kernal/bitmask/bitmask2.s -o build/bsw128/kernal/bitmask/bitmask2.o
ca65: Invalid definition: '1571=1'
make: *** [Makefile:408: build/bsw128/kernal/bitmask/bitmask2.o] Error 1

[mist64]

  make VARIANT=bsw128 DRIVE=drv1571

[xlar54]

Ah I see, thanks. Yes, it boots up (with 128 desktop added of course). This is great! Hopefully we can get the 1541 fix in and get it into the main. Good job dude.

[xlar54]

Im actually getting this issue after boot. I manually made the changes to a mist64'd main branch, so maybe ill just pull down rhalkyard's fork and try it:

[xlar54]

hmm same error on rhalkyard's fork and branch, so maybe im not doing something correctly afterwards. Im just adding 128 desktop to the disk (also tried adding 128 configure). No REU added

[xlar54]

By the way, any reason we call it mse1531 when the mouse is called the 1351?

[ytmytm]

By the way, any reason we call it mse1531 when the mouse is called the 1351?

It's my typo done almost 19 years ago.

[rhalkyard]

Thanks a lot everyone for your feedback! I literally booted GEOS for the first time just a couple of weeks ago, so I'm a total novice at this, but finding fixes for these issues will be a great learning exercise. How hard can it be, right? ;)

hmm same error on rhalkyard's fork and branch, so maybe im not doing something correctly afterwards. Im just adding 128 desktop to the disk (also tried adding 128 configure). No REU added

@xlar54 I hadn't tried that build path - I was using a cbmfiles.com GEOS128.D64 as a base, and as you'll notice, hadn't even got around to adding the 128 versions of DESKTOP and CONFIGURE to the makefile. I wonder if it's loading a driver from disk that is masking an issue in the built-in drivers - I noticed that with my builds, it seemed to want to load the first input driver from disk, no matter which one I built into the kernal. I'll look into it, but it might be a few days before I can put some quality debugging time in.

EDIT: forgot to add part of my reasoning there - $FD09 is the SetMouse vector in the mouse driver jump table, and it seems to be all zeroes, so it's probably trying to jump to it, and then hitting a BRK instruction.

[rhalkyard]

Looks like SetMouse is a 128-only thing; it gets called in the IRQ handler, immediately after reading the mouse position. The Hitchhiker's Guide to GEOS on page 429 says that the 1351 driver for GEOS 128 uses it to reset the analog paddle inputs. I've pushed a commit that puts an rts in the SetMouse entry in the mouse driver jump table, and that seems to work for now.

[xlar54]

Works like a champ. Nice job