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.

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.

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.

It works for me with the 1571 driver. Excellent!

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

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.

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

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.

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:

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

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

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.

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.

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.

Works like a champ. Nice job

I have added the C128 changes to the 1541/1571/1581 drivers in master, commit ab77d3e. This is based on ytmytm's disassembly.

Also, I renamed 1531 -> 1351 in commit 07c031d. :)

Also, we will need exomizer (pucrunch wont work on the 128 disk) and the script to detect is "128 desktop.cvt" is in the main directory, as it does for "desk top.cvt"

I've merged those changes into my branch; with the 1541 driver, the drive CPU still gets a JAM during boot, but the 1571 driver still works.

Can we go ahead and do a PR to get the 1571 driver into master, then create a separate issue for bsw128 / 1541 driver? Then at least it will build with the 71 driver.

Sorry about that; there have been a lot of other things soaking up my free time lately. I'll create a PR for it as-is, but I can't promise I'll be able to spend much time on it in the immediate future.

no problem, thanks for taking it this far!

#6

By the way, @xlar54, seeing that you seem to be interested in both GEOS and the 1541Ultimate, one of the other things that was soaking up my free time might be of interest to you - a GEOS autoexec to set the clock from the 1541U2's RTC, using the UltimateDOS interface. I ended up writing my own routines in assembler, but your UltimateDOS library was a big help in getting started. https://github.com/rhalkyard/ultimateRTC

Very nice! I have been studying the code for GEOS and would love to rip out the entire DOS portion of the kernal and replace with VFS code so that it natively works on the U64. But, techinically it would no longer be GEOS since none of the VLIR apps would work. Even thought about a D81 disk image bridge to allow it to work. ideas, ideas... and so little time :) thanks, will check into that for sure!

I've been thinking about doing the exact same thing! I think it would be feasible to write a driver that accesses a disk image through Ultimate-DOS, without breaking too much existing GEOS code. I tend to do most of my computer-y stuff over winter when it's too cold and snowy to engage in my other hobbies (classic cars are surprisingly similar to vintage computers at some level!), so any attempt will likely have to wait until then, but I'd absolutely be up to collaborate on something like that.

sounds good. Ping me anytime, here or on my own github