shoestring

I forgot to mention that I also had no click sound when the keys were pressed in basic. So the NOS GTIA finally arrived and I installed it, now I have my clicks back. Now the question is, where can I get a label from ? I know someone is selling a reproduction on eBay but I'd like an original. If anyone has a spare lying around that they don't want or knows someone please let me know. It doesn't have to be a 65xe label, 130xe one will do.

It's probably the 2114 colour ram or PLA. If you think it's heat related then try some freeze spray on the suspected chips.

I used some isopropyl and inserted a few drops inside the keyswitch, worked the keys up and down, side to side. Seems to have done the trick. But it seems you have a different problem.

I've been looking at the original C64 / disk based code through Regenerator 1.7 This is actually a much better disassembler than what I've used previously but I'm still using Infiltrator to look at the resources. I'm currently looking to see what I can re-use and what I would have to wre-write ( disk based I/O, DLIs..etc ) to see if this is feasible or leave it to someone with more experience. I work full time, so I'll only be able to work on this stuff during my own time.

Yes it's definitely one of the games that should have been released on the Atari. If I were going to port this, it would have to be the disk based version. There was a tape version which was missing a lot of features.

The tac 2 shaft always broke. I went through half a dozen of them before switching to another joystick.

No worries! Thanks for letting me know.

I'm looking at doing simpler platformer at first, one without sprites then I'll move on to something more difficult when I'm more comfortable with the Atari platform. Skool Dayz is on my todo list, this was a Spectrum port to the C64, I think the main difference between the two versions was the the c64 used hardware sprites just for the speech bubble.

What a great read. Thanks for posting that.

Sorry perhaps I wasn't clear. I meant the author of Infiltrator disassembler.

Here is a table I created on my whiteboard to help identify and map some of the resources before and after initialization. SPRITE DATA: $4000-$47FF Bullets, Explosions, Manta Deployment Vehicle SPRITE DATA: $4C00-$4FFF Manta Explosion MINI GAME TILE DATA: $4800-$4BFF ( Before Initialisation ) $A600-$A9FF ( After Initialisation ) SPRITE DATA: $5000-$5BFF Manta CHRSET: $5C00 - $67FF Super dreadnought tiles ( Before Initialisation ) $D400-$DFFF ( After Initialisation ) , This address range becomes Sprite data for the Manta's shadow ( generated during initialization ). SPRITE DATA: $6800-6FFF Enemy sprites CHRSET: $7000-$73FF CHRSET: $7800-$7BFF CHRSET: $7C00-$7DFF Minigame tiles ( Before Initialisation ) $D200-$D3FF ( After Initialisation ) The game uses an 8x8 character set which is then expanded/decompressed such that each letter/number requires 8x16 pixels.

As mentioned in the other thread here's the source for Uridium which I made from the original c64 game using Infiltrator disassembler. The uridium_dump.prg is the file I used to derive the source. I took the original tape image, loaded it up in VICE and set a breakpoint at $900 then dumped it. The build is quite simple, click on the batch file and it creates the two PRGs projectu.prg - uncompressed binary pjpu.prg - compressed binary ( exomized ) The source is far from perfect and I haven't had time to go through and comment the entire source or fix errors but hopefully it helps someone who is interested in porting a game to other systems, maybe even the Atari ? I don't know if anyone has noticed that Infiltrator disassembler does not handle opcode F8 / SED and represents this as data ( .byte $F8 ) Anyone know how to get in touch with the author ? I have included uridium.exl for Infiltrator disassembler in the archive which shows this ( see offset $0D77 ) c64uridium.zip

I'm not sure if I want to continue my Uridium port to the Taito board at this time, that project is more a proof of concept ( that I could take a c64 game and port it to hardware that is completely different ). The biggest issue with the board is that it doesn't have much RAM and Uridium uses a lot of it just for scrolling, I had to use the spare character definition RAM to pull that off without completely wre-writing the code. Although the hardware is more than capable ( foreground / background layers, huge sprite availability ) except sprites on an arcade system are normally 16x16, so I have to combine 4 sprites to make one 24x21 equivalent ( see screenshot ). The two independent layers means stars can be drawn on the background layer and there's no need to shift the stars in the opposite direction to scroll as done on the c64 for the parallax effect. I will share the disassembly of the c64 game in a new thread. uridium.mp4

That seems to be working fine now and I can build the xex without problems. I haven't tried building the ATR but I don't see why those instructions wouldn't work. I'm not sure which game yet, I'm going through the list of games on the c64 that I liked playing as I was growing up. Maybe something like LCP ( Little Computer People ) ?

Thanks for the source, this is very useful as I'd like to do a port of my own. There seems to be an issue with the very last portion of the build process. "mads -t -l flgame.asm" which creates the flgame.obx file. The intro runs fine but the actual game crashes on startup ( when running flgame.obx on Altirra ). I can run my assembled fl.obx from the main directory, so I know that's probably not the issue. It has something to do with the below steps which takes the raw dump from the debugger and compresses it to create the bin file. But what's odd is that the same steps used to build the intro work with no issues. I suspect that I need to make some changes to the flgame.asm source. My bin file sizes are slightly different ( fl.bin=26,486 flintro.bin=10,265 ), raw file sizes are the same as the ones in your original arhive. run Altirra, load fl.obx and use command: .writemem fl.raw 0800 LC800 7. Compress game image: 7z a -tgzip -mx=9 -so dummy fl.raw | gzip2deflate >fl.bin

Vertical shmups on arcade systems generally have the monitor orientated vertically. There's more of the playfield available and it makes the game easier to play. A lot of CRT monitors can be rotated also. I do that often with my 1084 when playing these types of games on my supergun. There's no reason why not to code it this way on home port, would definitely play much better.

This is awesome

I got thrown out of a computer store for apparently screwing up the workbench disks on an Amiga 2000. All I did was drag a few windows and double click on some icons. *shrug*

How difficult is it to implement soft sprites on the Atari ? Maybe we can get some extra performance from the 65816? I don't really understand the hardware limitations of the Atari so maybe someone can comment further but I imagine this process would be a lot of work and a different approach needs to be used. I actually made headway to port Uridium to the L System Taito board which runs on a z80 processor and has some cool features. I have a short demo and I'm currently implementing spirites and the super dreadnoughts ( not in the demo ) https://youtu.be/VkTtDLlTnaU I derived the z80 code from disassembling the original game code and turning that disassembly into a usable project that I could re-assemble on the c64, to understand how that code worked. It was a very long and difficult process to create a usable project. The process of porting from 6502 to z80 is also long and arduous. As I have to constantly debug routines side by side, check CPU flags.. Etc. Now the question is, is this possible on an Atari ? Would it be crazy to attempt such a project. In some ways it would be easier ( because of the CPU ) but the hardware is vastly different in regards to the PMG vs sprites approach. An Atari port of Delta would be cool though. But who would take up such a big task ?

I can't take the credit for that @thorfdbg suggested it earlier.

If your 800xl is socketed then try swapping the two 4051s around and see if your keyboard problem changes.

The diagnostic tool only tests 48kb of the dram, i wouldn't trust it entirely . Was the ram replaced at some point? If so, what speed are the ram chips?

Ok so I did a little work on the XE this evening. So I realised that I had the wrong MMU in there, there was some confusion over that ( see whole thread ). So I reprogrammed the PLD with the correct code. Machine still produced a solid red screen so I swapped the OS rom with a spare from the 600xl which I won't need anymore ( Antonia upgrade ). Machine fired up, needed a little colour adjustment. Picture isn't as good as my two XLs but it's still nice to see her live again.

You were probably into this old stuff and collecting it before you got married to her. She would have accepted your idiosyncrasies and now she's trying to change that? That's just unacceptable.

Thanks to @tf_hh for the crystals. So I tracked down the intermittent video to a dry joint(s) in the actual RF modulator, I re-flowed everything there with new solder so now the composite signal is completely stable and I no longer have to tap the PCB to get a solid picture A NOS Freddie chip arrived, installed that but still get a solid red screen except now the picture doesn't roll after a few seconds like it did with the old Freddie chip. I'm suspecting the gal16v8D device I'm using for the MMU might not be compatible in some way... The quest continues