|
Post by hydrophilic on Jan 24, 2018 4:38:59 GMT
Pyrofer, the original arcade uses a 4-bit optical encoder for the spinner. The "Atari Trackball" also uses an optical encoder, but I'm not sure of its resolution (because I never could 'hack' it on C64/128 in 'analog' mode). Zippy Zapp, I totally forgot about the driving controller! That would be a nice (although obscure) option. Thank you all for posting! But to be honest, the "input" is the least of my concerns at the moment... I really need to nail down the "output" code (like AVG/video and POKEY/audio). Anyway, it is clear there are a MULTITUDE of input options (joystick, keyboard, paddle, mouse, and derivatives [trackball, driving-wheel]). I will publish what I can personally test...
|
|
|
Post by hydrophilic on Mar 22, 2018 21:07:59 GMT
Full source code for Tempest 128 (Alpha) is available here. After creating a true "assemblable" source file of the original arcade (see prior posts), I spent a moderate amount of time writing code to emulate the PoKey chips and the Analog Vector Generator (AVG). The PoKeys were easy, and the AVG required a fair amount of work, but overall not too difficult. Mainly because they are well-documented! However, I got stuck on the Math Box (virtually undocumented). I tried for about 2 months to figure out what the arcade game was getting from (doing to) the Math Box. I was getting nowhere and Google couldn't help me either. It did find me some modern PDFs about people who built a Tempest (or similar Atari game) clone with FPGAs, but this was just hardware info... nothing that would help me (or any other programmer) with the Math Box. Luckily, before I gave up, I found a forum post that specifically asked about programming the Math Box. And some kind sir (or madam) kindly gave a link to MAME's Math Box implementation ( try this link). Well finally I was off and running! The current (alpha) version is a full emulation of the original arcade game. Since the original arcade game had a CPU running at 1.7 MHz with a custom graphic chip, it should be no surprise that my C128 emulation running at only 1MHz (or 1.3 MHz with "fast border") and using a "standard" graphic chip fails to play at full speed. If you (try to) play the Alpha version, you should see it is faithful to the original arcade, but runs *EXTREMELY* slow. This is just a "proof-of-concept" version... a foundation. For me, it is just a step to the next (Beta) version on the C128, but I also hope it will inspire a C64 and/or a Plus/4 port of this arcade classic. In particular, this Alpha version is confined to only one bank of 64K (within grasp of C64 or Plus/4)... and not all 64K is used! Anyway, I would like to improve the C128 version in time (if I can find the time). One big improvement would be to use traditional (pre-rendered) characters for game text, instead of emulating the AVG method of actually drawing each and every displayed character!! Another big improvement would be to use Sprites to render enemies which is almost automatic with VIC-II (and much much faster than drawing each enemy with my AVG emulation). Not only would sprites make the game faster, but it would make it more colorful!! (The alpha version is limited to just 3 drawing colors). And of course using both RAM banks (instead of just one) opens up even more possibilities... The sound, and overall gameplay, is warped due to the slow emulation in this Alpha version. Future versions should improve sound quality and (especially) game speed. I could go into the details about sound, game speed, graphics, etc. I could talk for hours about any of that. But I won't now. If you have any questions or suggestions about porting Tempest to the C128 then please post. Hopefully we can have a lively and constructive conversation on the topic...
|
|
|
Post by Pyrofer on Mar 22, 2018 21:52:13 GMT
How about instead of sprites you port it to the VDC and use 2mhz? It's great to get more 128 software but I am still pushing people to play with the VDC too
|
|
|
Post by hydrophilic on Mar 22, 2018 22:33:17 GMT
A version for the VDC would surely be possible. The higher resolution would be really nice! But for the life of me, I can't imagine programming 2x8 cells to fit this game. I'm not saying impossible, just beyond my comprehension! Maybe you or VDC 8x2 or Tokra (or anybody because open source) can work on a color VDC version. Or a monochrome VDC version? Should be easy to program once you have a working version (which we now have). In theory, this would be an excellent place to start (and then dive into color). Anyway, using VDC for full 2MHz CPU is a good idea, pyrofer. It's just not something I'm going to try anytime soon (read as = Open invitation to all VDC hackers).
|
|
|
Post by robertb on Mar 23, 2018 7:27:06 GMT
|
|
|
Post by hydrophilic on Mar 24, 2018 23:54:33 GMT
I must try it out with the SuperCPU 128. That sounds like a great idea! I tried to emulate SuperCPU using Multi-MHz VICE (just the 16MHz part, not the wide registers or new opcodes) and I was glad to see that my rate-control code kept the game from running too fast (I had no way to test without SuperCPU speed). There is also 2 clearly glitched rasters visible in VICE (due to timing issue) and there should be a 3rd one near the top. This was also expected since it was programmed without SuperCPU in mind. But most disappointingly, the game was crawling along as if it were running on a stock C128! Say what? I think the problem is the AVG code is running in an infinite loop! I put code in the AVG emulator to simply quit rendering if too many IRQs passed. Well this is happening with 16MHz CPU... which it should not (there should be more than enough time to draw a full frame). The AVG is designed to run a set of draw commands and then execute a HALT command. Then the game (either main thread or IRQ) can simply request a redraw of the same frame, or write new AVG commands and then command the AVG to start executing them. When the game first starts up, this is how the AVG is being operated by the game code. This is what I initially tested and debugged, and then just waited to see if it would work for the rest of the game, which it did. Based on the SuperCPU emulation, it obviously isn't working right. I remember seeing a VJMP opcode back to the beginning of AVG RAM a long time ago (while trying to fix the disassembly of arcade ROMs into truly assemblable and comprehensible text). Well I forgot about that until this SuperCPU investigation. So I'm stepping through AVG RAM right now to find out if this is actually happening. If so, then I can have my AVG emulator just halt at that point. If this works, not only will SuperCPU version be much quicker (hopefully real-time), but standard C128 might even run faster. I also noticed that my emulation can waste almost a full VIC frame waiting on the IRQ to switch frames. I made a comment about this in the IRQ code but didn't worry too much because the emulation was running so slow anyway. But now that I see it is clearly an issue with SuperCPU and can also improve standard C128 performance (perhaps not much) I will update the IRQ code for next release. Anyway, thanks for inspiration RobertB!
[Edit] I just found the infinite loop -- I updated the code to halt if it ever Jumps back to the start of AVG RAM (it always begins there). With this fix, the game runs at pretty much full-speed if I have Multi-MHz VICE set to 10 MHz, and it doesn't run noticeably any faster if I increase the speed. I've read the SuperCPU has to slow down when writing RAM, particularly if the RAM is part of the VIC-II bank. I don't know how true this is, but it sounds reasonable. But if the effective speed is 10 MHz or more, the new version should play full speed on SuperCPU! I did notice the emulation slows down just a bit when displaying the TEMPEST logo at 10MHz emulation. This doesn't affect game play, and it may or may not slow down at all with real SuperCPU. With the game running at full speed, it is really hard to control with the keyboard or joystick. So I'm going to work some more on the mouse code and then post an updated version. [/Edit]
|
|
|
Post by mrbombermillzy on Mar 25, 2018 20:44:47 GMT
@zippy zapp: Ive tried to get one of those Atari VCS Driving controllers to work on the C64/128. Unfortunately, the pinouts are not standard. The POT and FIRE were wired on the wrong pins (it had'nt been hacked or re-wired!) for a C64. I believe the one I have was for the Sears VCS, but I guessed that this would be the same as the 'standard' VCS ones, so your linked post is puzzling. :s Perhaps there are different types, but the one I have is definitely wrong for the C= 8 bitters! (?) hydrophilic: Great work there! As others have said, a VDC version would rock, but I understand how impractical this can be. I always respect someone attempting ANY game on the 128! Keep it up!!
|
|
|
Post by robertb on Mar 26, 2018 2:09:56 GMT
With this fix, the game runs at pretty much full-speed if I have Multi-MHz VICE set to 10 MHz, and it doesn't run noticeably any faster if I increase the speed. I've read the SuperCPU has to slow down when writing RAM, particularly if the RAM is part of the VIC-II bank. I don't know how true this is, but it sounds reasonable. There is also the RAM in the SuperCPU to consider. Up to 16 mb of SuperRAM. I look forward to that. Truly, Robert Bernardo Fresno Commodore User Group - www.dickestel.com/fcug.htmSouthern California Commodore & Amiga Network - www.portcommodore.com/sccanJune 9-19 Pacific Commodore Expo NW 2018 - www.portcommodore.com/pacommexAug. 11-12 Commodore Vegas Expo v14 2018 - www.portcommodore.com/commvex
|
|
|
Post by hydrophilic on Apr 2, 2018 23:06:48 GMT
I've applied the changes described above, and it works really great with my "emulated" SuperCPU. In fact, it runs so smooth and fast that mere Joystick/Keyboard control is not quite good enough! In other words, at full speed, you REALLY need a mouse/paddle to play this game! So I improved the mouse support and it works great now! I made sure to test for the "unstable" low bit of the mouse/paddle, and it seems to work fine... sadly I don't own a real mouse/paddle, so it may still be broken (but it is MUCH better than before). I've also "fixed" the sound to be NTSC/PAL exact (in frequency). However, the waveforms are not perfect because SID can't mix Noise with other waveforms like PoKeys can. So I guess "better" sound... but that is highly subjective! I also "fixed" the sound duration. The arcade runs with an IRQ of 180 Hz, but my port only runs at 60 (or 50) Hertz... so I had to 1/3 the duration of all original sounds (and 3x any frequency/amplitude sweeps). I'm almost ready to publish the final "alpha" version, but now I need details about C128 Super CPU. See this thread if you can help!
Thanks, mrbombermillzy! I just want to work on the 40-column port of TEMPEST. I provided full source code for anybody/everybody who wants to tackle 80-column mode! I would only consider writing 80-column version, today, if somebody paid me money! But nobody can legally pay me because this is an unauthorized port!! I mean, really, who owns the copyright to Tempest today (2018), considering Atari went out of business in 1996? According to Wikipedia (that's legally reliable... not!) the rights went to Hasbro Interactive in 1998... but what about now??
|
|
|
Post by robertb on Apr 3, 2018 8:07:34 GMT
|
|