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.

Sign up for GitHub

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

Jump to bottom

MEGA65 Support #364

Open
gardners opened this issue Jul 17, 2020 · 15 comments
Open

MEGA65 Support #364

gardners opened this issue Jul 17, 2020 · 15 comments

Comments

@gardners
Copy link

We'd love to help get Neohabitat running on the MEGA65.

Main differences of relevance are the internal 3.5" drive that can read 1581 disks, and the use of the on-board 100mbit ethernet interface, which could be used for TCP connection.

The extra RAM of the MEGA65 could be used to hide all of the TCP/IP mess, and just present a buffered serial API to the Neohabitat software.
@gardners
Copy link
Author

... and I suspect we could do the JSON/binary protocol conversion on the MEGA65 natively, as well.

@frandallfarmer
Copy link
Owner

Are you volunteering @gardners? The client source is available here, and has been successfully recompiled by at least one of our contributors (it's the binary we distribute.)

@gardners
Copy link
Author

Howdy,
Yes, I'm more or less volunteering, although I won't say no to anyone who offers to help.
My first step is to get a working TCP/IP library on the MEGA65's ethernet interface going. So I'll likely be missing in action for a while.
Paul.

@ssalevan
Copy link
Collaborator

Hey Paul,

I've been following the MEGA65 project for the past few years and we're excited that y'all would be interested in getting Habitat working on that platform. MEGA65 is some seriously impressive work and I'd be glad to lend a hand.

As Randy mentioned, the two big codebases here are:

https://github.com/Museum-of-Art-and-Digital-Entertainment/habitat

which contains the Habitat client source under sources/c64. This source is written in 6502 assembly with a macro system on top, powered by Macross:

https://github.com/Museum-of-Art-and-Digital-Entertainment/macross

Habitat has some fairly strict runtime constraints, particularly around how the bootloader interacts with the disk drive. If there'd be a good time for you, we can hop on a call and discuss these details in further depth.

Hope all is going well over there for y'all and all the best!

@guybrush01
Copy link

guybrush01 commented Jul 19, 2020 via email

@gardners
Copy link
Author

Howdy,

Thanks for the kind offer Guybrush, and for your support by ordering one of the DevKits.

I'm thinking that it will be necessary (and a good idea) to patch the client so that it doesn't use a 1541 fast loader.

Paul.

@glake1
Copy link

glake1 commented Jul 19, 2020

Hi Paul,

I'm the contributor that rebuilt the Lucas tools and makefiles (also I'm a Mega65 fan and have my dev kit ordered!!) A few things to be aware of - not to discourage, but just to understand the scope:

  1. Full source compiles, links, and matches the original binaries, but the final game relies on hardcoded memory locations and fixed sections that break if you change source and re-build, because naturally the linker moves code around. If you replace existing code with something the same size or smaller and pad it, then you can get changes to work, or better yet hack a jsr out to your patches, and build those in kickasm. Unfortunately not a lot of free mem available on a C64 native when the game is running.

  2. The Lucas loader is a both a custom fast loader as well as a sector based lookup. No filesystem so to speak, so one idea might be to change the sector addresses into corresponding files based on track/sector number if you want to use standard DOS instead of a trackloader.

  3. The Lucas loader is tightly coupled with the modem driver - they share nmi's and expected timing. This makes it hard to replace just the filesystem independently from the modem. People have thought they could bump up the baud rate with wi-fi modems, but it requires the filesystem to be rewritten too.

  • Gary

@frandallfarmer
Copy link
Owner

Thanks for articulating the dependencies, @glake1.

Unlike about anything else the existed at the time on the c64, Habitat was able to do comm, go to disk, and still simultaneously play (animate, take commands, etc.) This was a crazy hard trick back then. [It also lead to the Mother of All Bugs, but that's another story...]

@gardners
Copy link
Author

Great to hear there are other MEGA65 fans lurking here. We hope the machine brings you as much fun as it has for us already :)

ok. So for the MEGA65 we would want to replace the disk driver AND the modem driver, in any case.

We would do direct sector reads from via the F011 floppy controller, and use hooks to the TCP/IP code I am running. If necessary, both could be located above 64KB.

But my gut feeling is that if we know the area of memory that holds both those, and the entry points into them, that we can then perhaps generate the alternate code that fits in that footprint.

How big is the combined modem/floppy code?
Does it have more entry points than a hungry hydra?

Paul.

@frandallfarmer
Copy link
Owner

Please, check the source. :-)

@glake1
Copy link

glake1 commented Jul 19, 2020

I don't think it is too bad, as in the code for both drivers is in the same set of source files. I'll do a little digging to see if I can provide some bounds.

@glake1
Copy link

glake1 commented Jul 21, 2020

OK, I took a short time to revisit the code looking for both rs232 and disk i/o. There is a bit of a twist here: Source code to all of the game exists, and code to most of the boot loader, but there is a small part that is a combination of pre-built binary and source that is packaged together and placed on specific sectors of the disk. I was reminded of this when looking at the disk layout tools that we re-created. This loader is part of the hand-off from the front-end and old Q-Link launcher (replaced by the NeoHabitat launcher) to booting the game code. I'm pretty sure that this is where the disk driver is downloaded to the 1541 and game starts picking up the rs232 connection.

Nevertheless, we have the initialization source code, so with some effort it could be re-written. It just complicates things a bit if hoping to build the whole game completely from source. The code to concentrate on is: init.m, protocol.m, rs232.m, vblank.m, zpage.m, page4_space.m, diskdriver.m, loader.m, diskdos.m.

If I were going to embark on this project, I'd probably start with making sure the handshake from the launcher to the full game stays alive after the handoff (The modern MADE launcher is written in C and should be in this repository). The full game can just be unpacked to c64 RAM in one before you need to start worrying about replacing sector-based disk IO routines... though the first thing that happens is the avatar and room start getting loaded right away.

@gardners
Copy link
Author

Ok. Do we know where in memory this all sits?

@glake1
Copy link

glake1 commented Jul 21, 2020

There is good news on that front, because the Lucas macro assembler and linker outputs a full symbol file for the project, so that is already in the code on here.

@StuBlad
Copy link
Contributor

StuBlad commented Apr 16, 2023 •
edited
Loading

Ok. Do we know where in memory this all sits?

Hey @gardners I know this is a few years late but if possible I'd still love to see this happen.

I believe these files may be of relevance:

https://github.com/Museum-of-Art-and-Digital-Entertainment/habitat/blob/master/sources/c64/all.sym

https://github.com/Museum-of-Art-and-Digital-Entertainment/habitat/blob/master/sources/c64/Main/Makefile

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@ssalevan @frandallfarmer @gardners @guybrush01 @glake1 @StuBlad