Open gardners opened 4 years ago
... and I suspect we could do the JSON/binary protocol conversion on the MEGA65 natively, as well.
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.)
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.
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!
Hi gang!
I bought one of the limited edition 100 MEGA65 prototypes that were available for GPB 999. Once I receive it, I'd be happy to loan it to anyone who needs a real MEGA 65 to prototype and develop on. Just let me know!
Thanks,
John
On Sat, Jul 18, 2020 at 11:42 AM Steve Salevan notifications@github.com wrote:
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!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/frandallfarmer/neohabitat/issues/364#issuecomment-660500558, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPXMUHOCZCXTJ3RZF4WVC3R4G7HLANCNFSM4O6H2HVA .
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.
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:
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.
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.
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.
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...]
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.
Please, check the source. :-)
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.
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.
Ok. Do we know where in memory this all sits?
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.
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
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.