Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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. #4

Open
xlar54 opened this issue Dec 4, 2018 · 26 comments

Comments

@xlar54
Copy link
Contributor

xlar54 commented Dec 4, 2018

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

@rhalkyard
Copy link
Contributor

rhalkyard commented May 25, 2019

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
Copy link
Owner

mist64 commented May 25, 2019

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
Copy link
Contributor

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
Copy link
Owner

mist64 commented May 26, 2019

It works for me with the 1571 driver. Excellent!

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

@ytmytm
Copy link
Contributor

ytmytm commented May 26, 2019

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
Copy link
Contributor Author

xlar54 commented May 26, 2019

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
Copy link
Owner

mist64 commented May 26, 2019

  make VARIANT=bsw128 DRIVE=drv1571

@xlar54
Copy link
Contributor Author

xlar54 commented May 26, 2019

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
Copy link
Contributor Author

xlar54 commented May 26, 2019

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:

bsw128

@xlar54
Copy link
Contributor Author

xlar54 commented May 26, 2019

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
Copy link
Contributor Author

xlar54 commented May 26, 2019

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

@ytmytm
Copy link
Contributor

ytmytm commented May 26, 2019

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
Copy link
Contributor

rhalkyard commented May 26, 2019

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
Copy link
Contributor

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
Copy link
Contributor Author

xlar54 commented May 27, 2019

Works like a champ. Nice job

@mist64
Copy link
Owner

mist64 commented May 27, 2019

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

@mist64
Copy link
Owner

mist64 commented May 27, 2019

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

@xlar54
Copy link
Contributor Author

xlar54 commented May 27, 2019

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"

@rhalkyard
Copy link
Contributor

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.

@xlar54
Copy link
Contributor Author

xlar54 commented Jun 16, 2019

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.

@rhalkyard
Copy link
Contributor

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.

@xlar54
Copy link
Contributor Author

xlar54 commented Jun 19, 2019

no problem, thanks for taking it this far!

@rhalkyard
Copy link
Contributor

#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

@xlar54
Copy link
Contributor Author

xlar54 commented Jun 19, 2019

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!

@rhalkyard
Copy link
Contributor

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.

@xlar54
Copy link
Contributor Author

xlar54 commented Jun 20, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants