Wrathchild

Is there a Commodore 64 emulator with a monitor that can allow you to trace execution and output the tracing to a file, e.g. Program counter, instruction and register states? Ah, should add that I'd need a Windows based one. Thanks, Mark

I never went away Search around these boards for info on Elite's lack of progress... certainly won't be resurrected in the near future PM me for any further followup. Best wishes, Mark

Similar here, the first UsbTest disk didn't detect these devices, but the latest one does. I also have a little IrDA device but as the function of that is limited against an Ethernet device, I'll not concentrate on that. What's nice about these devices is that, I think, you can use a small transfer buffer between the device and your driver software, e.g 8 bytes. Saying that though, making the driver work through the OS's I/O routines/handlers would be desirable. General Question: Has any work been done to make CC65 libraries (in 'C',ASM or a mix) for use with the USB cart? Regards, Mark

Great idea, anything to do with the Contiki/uIP work done so far? I have a USB cart and would like to turn my hand to a driver for those cheap USB to Ethernet adaptors, but a few other bits to do first Best Wishes, Mark

For any aspiring ROM makers, this may help a bit. Primarily it highlights the differences in the XEGS, MegaCart and Flash Cartridge models but also shows a way of using CC65's powerful assembler and linker to easily construct ROM images. Ask any questions about it can be posted on this topic and I'll try to help as much as possible to describe how/why things were done. Also it gives away a nice little simple Run-Length-Encoder that I knocked up in Java to ensure that blocks don't span cartridge page boundries. The decompression code is in the routine 'load_data_file'. Ultimately the three separate source files are common enough so that one version containing #ifdef statements to control what is included based upon the selected cartridge model could have been developed, if someone would like to do that and show me how the makefile could be used to build all 3 I'd be grateful, mine seems to rebuild the ROMs even when the object file hasn't changed. Regards, Mark Gaunt128.zip

It looks to be a bug in the 3.1+ code. After having switched out the ROM, when you write to $D500 to switch it on again, the SWXEGS model only sets the bank at $8000->$9FFF and doesn't re-enable the last bank of the ROM to $A000->$BFFF properly, hence a jump to routine there was hitting a BRK command and the system goes potty. However, I did have the issue you saw occur in my 4.0+ so I'm re-posting my current image just in case. Regards, Mark G_xegs.zip

I'm getting a crash too in 3.1+ - although when the cart is attached it goes straight to self test, but when you close and open the emulator again then the garbage happens, followed by the crash. No Mindscape title is shown though. The new MegaCart image works in 3.1+, again the emulator has to be closed and re-open for it to take start correctly. Both images work OK in the 4.0 emulator. I'll have to delve further - probably to do with which bank is loaded first when a coldstart is done. For XEGS $A000->$BFFF is always bank 15 (of $0->$F) so shouldn't have a problem there, and the MegaCart sets Bank 0 (of $0->$7) for the 16K between $8000->$BFFF. Are you using Steve's Flash enhanced 3.1+ emulator? I think I recall experiencing weird reset behaviour with that, I'll need to find the original 3.1 to compare. Regards, Mark G_mega.zip

(This topic missed the Forum migration, so I'm reposting it ) FYI - A new FlashCart image of this game is available on Classic's forums: http://www.atarimax.com/flashcart/forum/viewtopic.php?t=243 At the request of Nir Dary, I've also produced an image for the Switchable XEGS cartridge model. Seems to work OK in A800WinPlus, but please feedback if you find otherwise. Anyone need a MegaCart version too? Enjoy, Mark (original XEGS image removed) G_flash.zip

Are the sources to "Black" (or is it Blark?) or Ars Mori (by Tristesse) available anywhere - that's some impressive stuff I found these on a demo compilation DEMOS014.ATR Thanks, Mark

Check this thread: http://www.atariage.com/forums/viewtopic.php?p=823777

Amazingly, I've dug up the old code Doesn't appear to drive much itself - just reads for the A8 side. But worth a look port.zip

Think back (and find the thread ) for the W.C.Leaderboard work I did. I think a good trick here is to use colour 3 as the background. This then makes the usual background colour available for the foreground (?!) The borders can then be made by overlaying the missiles, so you lose in that respect. Conclusion - don't always go for black as the obvious background colour. Think further back and the Barbarian work shows that, with careful design of the player's software sprite, the animation frame resolves itself on char (4 pixel) boundries. Food for thought. Regards, Mark

Remember, now we have the luxury of large bank switchable carts, images can be pre-created at multiple X/Y positions and then the correct image extracted directly when required, cutting out the need for large numbers of shifts preparing the sprites.

Hi, When I used to develop on an STE, cross-assembling for the A8, I had a parallel cable which split into two joystick connectors. On the XL you'd load a 'bootstrap' loader from disk, then this would sit and wait for instructions to come down the cable. Using the 4 bits of each port to make an 8-bit value and the triggers for handshaking, transfer rates were quite good. All that you needed to do on the ST was to 'print' the binary you wanted to send. Pretty neat. I did also manage as well connect an XL and a C64 together via a single joystick extender cable with an female-2-female adapter on one end. using a reset cartridge I had to type in the hex code for the 'send' routine somewhere into the C64 memory and then run it. This way I managed to get across the memory for some 'screens', e.g. "The Sentinel" loader screen - so that I could then play with the data on the Atari. There must have been an easier way?! Best wishes, Mark

Oops, that should have said: Hence if you start with the original Gauntlet, you can't put the Deeper Dungeons disk in between levels.

I think they maybe be cheating a bit with this, maybe there's 128 levels and these can be mirrored and flips to produce 4 versions of each? I'll fool around in the emulator to find out. 1 side of disk (minus the 'flip disc' message code) doesn't give enough space for 512 levels. AFAICT, there are no levels on side 1. A check is done by loading the 1 first sector and then the second sector one byte on from the first. The last byte of the second sector needs to be $FF and then first byte of the first sector gives the level disk 'id'. Hence if you start with the original Gauntlet, you can put the Deeper Dungeons disk in between levels. I don't think the game ends. When the players die the engine just waits for someone to rejoin? Regards, Mark

Does anyone know how many levels there are in the Atari version of Gauntlet? Looking at the code & second disk shows that each level takes 4 sectors with level 1 starting on sector 4. I think maybe its 118 levels as there appears to be a program starting at sector 486, though I haven't checked out what that code is for yet. Also there is a check between the level and the value 118 in the post level loading code which maybe used to do something like mirror the levels, again I haven't check yet. Thanks, Mark

Sheddy would be well placed to comment if such an engine is possible?! Would a simple (basic) gr.10 screen suffice? 9 colours and 80 pixels wide would make shifting data a bit quicker (less of it) and if things were fast moving then the lack of detail would not matter so much, although player/missiles could be used to enhance the display. Mark.

I've added rough Flash cart image support to this release. A basic test with my Eidolon image appears to function OK. FYI : the exe attached was built using VC++6 & DX8.1 SDK. Source diffs can be supplied to whoever wants them. These are the comments for the two carts: AtariMax 1 Mb Flash cartridge - This bank-switched cartridge occupies 8 KB of address space between $A000 and $BFFF. The cartridge memory is divided into 16 banks, 8 KB each. The 4 lowest bits of the address written to $D500-$D50F select the bank mapped to $A000-$BFFF. Writing to $D510-$D51F disables the cartridge and any write to $D520-$D5FF is ignored. AtariMax 8 Mb Flash cartridge - This bank-switched cartridge occupies 8 KB of address space between $A000 and $BFFF. The cartridge memory is divided into 128 banks, 8 KB each. The seven lowest bits of the address written to $D500-$D57F select the bank mapped to $A000-$BFFF, bit 7 disables the cartridge." The two models differed in that the default bank for the 128KB cart is the first bank (0) wheras the 1024KB cart defaults to the last bank (127). However, its highly probably that I've got something wrong, however this now lets me easily debug a current task of mine - putting "Gauntlet" into a 256KB flash chip (that can be run in an 8Mb cart). Regards, Mark atari800win.zip

Looking at the help file and source code, all of this is there already! Simply type 'B ?' in the monitor for details. Regards, Mark

My flatmate and I used to have many great games on my STE whilst I was at uni Curling the ball in from a corner kick was often a simply way of getting some goals on the scoreboard After you got used the difference in after-touch control, it was nicer in many ways to KO2 but didn't quite have its fast pace. Mark

Hi, Other than it not yet supporting flash cart images, I'm happy. Seeing as that's not yet in atari800-1.3.5 I can see why. Revised aims will be to add the import CC65 produced labels, which seeing as they've already added X-ASM label handling shouldn't be too much trouble. Good to see file tracing there :wink: From a developers point of view, I still find the single breakpoint very restricting, I think the facility for multiple breakpoints, each with an enabled/disabled status, should be included. Later, perhaps some 'break on condition' rules would be useful. E.g. run until register/contents of memory address = value Regards, Mark

Already converted, the picture doubles the x-pixels to show what it would look like on the A8. It was SS, I fired up KO2 on WinSTon to confirm. Tip: Old joysticks are better then joypads - I couldn't get into the game at all! Bit like Arsenal really Cheers, Mark

Way way back... IIRC, Harlequin (Steve aka JetBootJack and others) did want to produce KickOff. I was asked if I'd like to have a go (having produced the Speedball scroller - albeit a slow scroller ). As I was too busy at university I never got around to producing anything. Though I did speak to Steve Screech a little bit about it when he was on the Anco stand at one of those UK computer fairs at Wembley one year. Anyway, one thing I did do was to take the men from KO2 or Sensible Soccer (I can't recall) and produce A8 equivalents of them. Here's a piccy and the data statements if anyone feels like trying to animate them. The colour palette is: 0 - green - pitch 1 - red - Team 1 Skin/Team 2 Shirt 2 - white - Team 1 Shirt/Team 2 Skin and Ball 3 - black - hair, shadows, shorts I think the A8 could do with a great soccer game! The Zeppelin one was painful to play! Enjoy, Mark footy.zip

Don't forget, especially flash cart owners, that images of the ROM converted Atari 8-bit versions (sorry 5200 owners) were available on these threads. The Eidolon http://www.atariage.com/forums/viewtopic.php?t=41564 Koronis Rift http://www.atariage.com/forums/viewtopic.php?t=42731 I can't recall anyone wanting to produce these commercially, guess we could as the Lucasarts people if they'd mind? Regards, Mark