Wrathchild

You can use Inform and use a v3 target when compiling. The resulting output I think can then just be written on an exiting infocom disk image, i.e. over the data part which appears after the interpreter code. If your game is large then you may need to span disks and so would have to split the data file. Maybe start small, e.g. try the 'Alice' sample

Erm, if you had forward velocity you'd be looping the loop wouldn't you? Take games like Domark's/Parker's Star Wars and even Elite for that matter (side / aft views). There is no h/w scrolling going on here just a few stars' positions being calc'd relative to how you've moved and which direction you're pointing. Probably Novagen's Mercenary (again no scroll above ground, not sure about underground) better portrays the scene you want? Saying that, Space Harrier should be the closest thing? You've lost me here I'm afraid, the game 'Blaster' springs to mind... carpet sequence in 'Master of the Lamps'? Still no h/w scrolling. Is 'Zaxxon' close or a half-way house? Vaguely with you, but a bad bit of cut and paste there?! What, why, where.... do you want a 3D game or it to still be 2D with a 'zoom' feature? Is this from first person perspective or camera behind? Track and Field so you look down at the ground say after jumping a hurdle? Is the joystick controlling your 'view' at this point or is forward for running forward and back to run back and left/right to get disqualified for running into the opponents lane, or does how fast you do the left/right wiggle still determine your speed? Er, so you want to make individual Mario 64 type world game using the concepts out of each of these titles? Even the 3D engine shown on the Numen demo tells you the 1.79Mhz just ain't up to that. It didn't and I wouldn't think so. Certainly a multi-way 2D platformer with the speed of Sonic would be lovely to behold.

Due to the aspect ratio, this version couldn't be utilised as a whole http://g2f.atari8.in...s_wratchild.png http://www.atariage....t/page__st__384

A mini-dos would have to also use its own variables, you cannot use any existing OS stuff due to its use of zero-page, page 3 etc. Seeing as the game already had its own I/O routines for its sector encoding I would better see that could be removed and ported first to a 'standard' sector model. The cart image has the existing I/O rewritten to read from the equivalent offset into the images held in ROM and so no issue there. The issue, and place where I've stopped, was more down to the nature of the I/O routines also being coded into the modules/overlays (e.g. going into an Inn). This means that these also need to be patched, either after they are loaded (as I do currently) or patched and re-saved into the disk images (which requires encoding). Saving back to the disk (which seems to occur with the module loading/unloading) is a City thing, the Dungeon doesn't have the same level of protection and so would theoretically be more easier to do as a cart. In an 8Mbit cart you can still put an 040 and an 010 chip in there, so the game image can reside on the 040 and character and game state stuff can go on the smaller chip with 16K erase sectors. Also it wouldn't need to be erased each time, a bit-mask header could be used to indicate the next free slot and the save writes to that slot and then knocks off a bit (1->0) from the header. When the header is all zeros then the sector is erased and started again.

Though not an A8 title, the exchange game in 'Paradroid' was always one of my favourites (enough to have half ported it in the past)

Although I'd love to say "never say never", this project took a long back burner as the focus required to get it to the next stage is quite large and finding such a window just hasn't happened for too long. Ideas (in my mind) of picking it up keep occurring but regulars here may have notice I've "backed out" a little of the A8 coding scene over the last year and that's been a conscious move as requiring more focus on family life has pushed my involvement here to mainly reading threads and periodically posting. Specifically the need for a Cart version of the City & Dungeon has fallen away IMO as there are the SD drives that can mount images and I believe these can permit a fan to run these games reasonably well, so I'd recommend taking a look at that option.

Maybe porting Pele's soccer from the 2600 would top it?

Some footballer graphics here

I could have sworn I once saw a video either on AtariAge or maybe atarionline.pl which I think was a horizontal scrolling thing with simple 'line' platforms but had a running stick-man who could do Matrix-like things like swap gravity and end up running on the ceiling. Does anyone re-call something like that? Was any 8-bit port underway?

Not searching hard enough Sorry, that's not fair... here was an approach one could take, but requires knowledge behind the play routines of the C64 title.

With something like the ABBUC/AtariMax USB Cart (using a USB-2-Ethernet adapter) or the new Atari 8-bit Ethernet cart, the TCP/IP stack would be implemented by the A8. By having a cart with an onboard device such as the PIC18FxxJ60 family then that could be taken care of by the device's micro and so 'free-up' the A8 to some extent (would still need to 'marshal' the data to the A8 (possibly through some shared RAM that could be banked in?). Could a SIO-2-Ethernet type of device could also work a dedicated micro?

Would it be easier to 'stream' this from the device (I'm assuming that this would be IDE based) in the same way Mr Atari's videos were done, as experiments have been done with 'colour' playback? The engine behind the Dragon's Lair games (certainly on the PC) have a tiny script that is basically just waiting for a point in playback to allow the user to push the joystick in a direction or press the button and then that determines the next sequence to play and then that sequence could be linked to 'death' after playback. This way the original audio could be re-sampled and used. Trying to code up the screens in terms of animating sprites/chars over backgrounds seems like a lot of work? (granted the resolution maybe worse in a streamed solution but the motion going on may cover over some of that) Mark

Welcome Shahid, for me your game was great example of something 'polished' meaning the developer took the care over little touches like use of colour changes in DLIs, plus that pause mode was just zany. I never did manage to complete the game, just came close on one occasion IIRC. I also recall reading around that time in C&VG the 'diary' which was entertaining. Regards, Mark

Excellent Tezz, many many thanks for spotting that What had thrown me initially was the table at off_0_6C0, as I'd mistaking interpreted related code as making this area to be considered a 'bss' segment candidate (initially all zero). Here's the initial changes to the project code. zybex_code_patch.zip

Wasn't able to spot anything, the table that was at unk_0_D800 is now at $F000 and seems to behave the same. So does the table UNK_0_A700, now at $C000.

Thanks, I was able to break when $44EE was written to and see that this looks promising. This area is setup with a table copy from an address calc'd using the table at unk_0_7CC (the 'high' value being held at byte_0_DD) so I'll go back and see what the original is doing and compare where it gets its data from.

I would like to ask for some fresh eyes to try and help track down a problem I have with this game. Background is that I initially wanted to see if the working RAM of Zybex was < 16K in order to determine if it was a candidate for a 5200 port. Sadly it turns out not... however I had the (senseless) idea to see if I could make a cart version that would run on 48K machines rather than needing the XL/XE's memory under ROM. So having gone through a dis-assembly process and correcting pointers and tables etc where necessary I was able to get the source into a state where I'm building an executable (still for 64K) and everything is pretty much there; titles, music, levels & gameplay - however one important bit is missing and that is the power-up and tokens don't appear when an enemy is killed. The items are 'there' because you can cross over them and they are picked up, just not rendered. Source labels have names such that they identify where (in the original tape version) data/code was originally located, and mads produces a lst file for their new locations. I've tried outputting text traces (from A800WinPLus) and used Altirra but am starting to lose hope of finding why, so if someone can help me get past this hurdle then the next step of putting into a cart image can begin. Cheers, Mark zybex_work.zip

Hi, A few useful links: Atarimax 8Mb cart compatible compilation of Synapse titles Original announcement of Sunmark cart A thread that discussed some of the 'rights' aspect For me the Sunmark cart should have also either made the effort to fix the XL incompatability of some titles (or take advantage of existing patched versions). As the boards are no longer available then an Atarimax alternative is a good option. Mark

Though having not investigated but having played some of the CTH titles, my impression would be that he had 'wrapped' the existing interpreter with a loader (and from what I remember also may have hooked into some of the screen drawing parts, e.g. dlist, to brand it). The Z-file containing the adventure's compiled code contains its own header and so simply placing this starting at the correct sector on the disk would mean the interpreter would detect it and run fine. So many of the V3 examples (e.g. Alice) could have been downloaded and used 'as-is'. This probably had the advantage too that these works were smaller in size than a full-blown Infocom title and so would fit on just one side of a disk. FYI: For the cartridge port, code was assembled to run in the cart-bank area ($A000-$BFFF) and Z-code and working RAM is located below this, wheras the Infocom interpreter loads low.

This was covered here?

Best give the emulator here a go as that fixed a similar issue (I think)

The A8 interpreters will only manage V3 titles. I looked into this a few years back when making MaxFlash cart versions of the Infocom games (no disk swapping etc). The best option I think is to reverse engineer the C64 Border Zone, using Frotz sources as a reference (I think that's what I used when doing the HHGTTG V3 code), and compare the BZ V5 engine with the A8 V3 code and then make a new cart-based engine by fixing up the relevent bits, which should be around disk access and memory usage (maybe meaning 128K RAM would be miminal requirement?). Probably worth including the V4 engine from the C64 at the same time. From what I remember the differences between V3 & V5 meant much V5 syntax couldn't be targeted at V3 and trying to rewrite those parts was too difficult. I think I was looking at the Inform sources for Scott Adams or something like that. Ended up just making a special cart for his games having done Brian Howarth's beforehand. Those can be found over at AtariMax. Mark

Fandal did the port, I helped with some checking and it was his work that inspired me to take the route of attempting the A8 to 5200 conversions.

Kid Grid has that affect on me

LOL! As I'm in the Czech Republic at the moment my better half would probably welcome the display Kids would have to have gone to Summer Club or grandparents first though! Here's where I'd got with the BBC port but I'd like to go back to the C64 port at some point, but real-life is requiring my attention for a good while.