tcdev

No. Not it is not. An FPGA implementation is no less an emulation than a software emulator. It is arguably easier to make (most aspects of) an FPGA implementation more accurate than a software implementation. But that doesn't take away anything from the fact that it is still an emulation.

Good to hear you guys are reverse-engineering the original. I've been thinking about porting an Atari 8-bit game to the TRS-80 Coco3, and Jumpman was a definite candidate. A commented disassembly might just seal the deal!

I didn't meant to say it would change the way the game plays, but rather how the game works. The outcome would, in theory, be exactly the same, so I agree with you there! I'm just being a pedantic purist. Ah rotation - I use the term shifted. Now I'm on the same page! I haven't calculated the hit I take using the lookup tables but caching is an interesting idea, especially considering I have 64KB free memory. Considering there's a maximum of 40 sprites on the screen at any one time (and many of them the same), it wouldn't take a silly amount of memory to cache just what's being shown. Obviously as sprites change into other sprites there'd be a need to modify the cache, but it might be worth looking into as well... it all comes down to how much speed I can coax out of simpler optimisations on the Coco3 first. But definitely going to look at sorting given your metrics! Yeah it would be scary to attempt without reverse-engineering the original. Amazingly, that's exactly what Sockmaster did when he ported the Z80-based arcade version of Donkey Kong to the 6809-based Coco3, also adding emulation of (scaled-down) hardware tiles/sprites and sound hardware. The results are simply incredible, and that project has been an inspiration for me for my later porting projects, in particular Donkey Kong for the Neo Geo (in 68K ASM, 50% done). Anyway, the work you've done with automated translation is very impressive indeed! I've taken a preliminary look at Alien 8 and Pentagram and was encouraged by the similarities in the core engine - especially Alien 8. And from what I saw I didn't think shooting was too radical an update; just another sprite whose update handler made it move and destroy other objects?!? Perhaps I'm not remembering properly, or perhaps I'm thinking that's how I would have added it to the basic core?!? I'll have to study it in more detail if/when I get around to it. Right now I'm feeling a little over Knight Lore; 5 ports in 3 different languages is getting a little old. Many years ago I reverse-engineered the arcade Space Invaders - almost but not quite to the degree that is now on Computer Archeology - in order to patch it to run on the TRS-80. I'm thinking of revisiting that just for a diversion from filmation, and tinkering with the idea of porting it to the Coco3 and, since it's already in 8080/Z80, the ZX Spectrum. Both of these machines have plenty of Space Invaders clones/remakes already, so it wouldn't be particularly exciting, but IMHO cool to have the original code/logic running for a 100% faithful port. I'm still in the process of seeing how that would work on the respective screens - the Coco3 at least can do 320x225 which is just enough vertical resolution for invaders if the top two lines of text are moved to the side of the display (which I'm sure you've seen before). Or perhaps I'll do something different (I have a couple of Apple II games in mind), and I'd still like to tackle an Atari 8-bit game. Either way I'll probably do one project before I tackle another filmation game again.

The Coco3 comes stock with 128KB, so when Knight Lore is running there's 64KB of free memory sitting there idle. Using another 16KB is neither here nor there. However, in light of your comments, I went back and looked at the objects that require HFLIP in Knight Lore; the answer is, not many. There's several background objects (walls etc) that need flipping, though of course they're only rendered when something moves in front of them. Backgrounds aside, there's just the player, the ghosts and the portcullis that moves up/down. Like your tiny spider, these objects, particularly when there's two ghosts on the screen, could require multiple flips per frame. I'll have to evaluate the likely improvement, though implementing the memory page banking would be quite trivial. I'm more interested in your sorting - I hadn't gotten around to profiling the software yet - and I'm very interested to learn that it spends 30-40% of time doing so! You're right, the 6809 has two index registers. Throughout the game I use X,Y for IX,IY on the Z80 version, which works out nicely. Of course during rendering etc those get saved and re-used. I'll have to digest your optimisations. Part of me is hesitant to use them, only because the intention was to port the software as-is, warts and all, except for routines that must be changed like rendering. There's a couple of bugs in Knight Lore that write to address $0000 which is ROM on the Spectrum, and therefore harmless. Not so on the Coco3 - I've got it mapped to video memory so the screen gets garbage. Those types of bugs I did fix too. Mind you, if it makes the game more playable I might be forced to relent on my idealism! Either way, I'll study your code and try it out to see what savings I get too - thanks again for making the source public! I'm a little confused at your use of the term 'rotation' and how that relates to HFLIP? IIUC they're one-in-the-same!?! What's funny is that you use, eg. "z80_b" to store intermediate results in Z80 registers. I used exactly the same names for mine! So at the end of it all, do you think there was benefit in using automated translation as a starting point? Or in hindsight would you have hand-coded the entire program in 6502? Depending on the reception to my Coco3 Knight Lore, I'm considering doing the other two filmation games as well (little point going to the effort if no-one wants to play them). They should be much quicker as the 'core engine' has already been done, even if it requires minor tweaks. I'll probably (also) do C ports for them too - maybe.

Yes, I am aware of that, thanks for the heads-up regardless! My port for the Coco3 is from the original ZX Spectrum, which I reverse-engineered completely. Disassembly here. I wanted to use the Spectrum version, rather than the BBC version, simply because it was the original, and I'm also a lot more well-versed in Z80 than 6502. I've also done a C port, which I'm finalising the debugging of atm, completely faithful to the original. It runs on the Amiga, amongst other machines, and I would assume would also port well to the Atari ST. The C port has the option of using the Amstrad CPC graphics, and soon also Mick Farrow's modified graphics.

Nice work! I'm impressed with the performance you got out of it! I've just finished a 6809 port of Knight Lore for the TRS-80 Coco3. All that is left for me to do is optimise parts of the code as it's a little slower than the Spectrum atm. I need to study yours! Did you find that HFLIP'pIng was a big factor? The stars have aligned perfectly and as it stands on the Coco, the Knight Lore sprite data occupies almost exactly 16KB, aligned on two 8KB MMU pages. I plan on pre-HFLIP'ping every sprite and storing them in alternate memory pages. HFLIP then simply requires paging in the right 16KB bank, 2 write operations on the Coco. VFLIP on Knight Lore is only used once - on the menu/text screens for the border. I'm tempted to add a few extra sprites and do away with the VFLIP logic altogether.

One thing I thought was pretty cool that was thrown about during the whole RGVS fiasco was the suggestion that the cartridge adapters had the FPGA bitstream stored on them. It would be nice if you didn't have to program the Cyclone V with the "correct" image before inserting a cart! I'm assuming the MAX10 would be a 'static' design in that the same image worked with all Cyclone V images? Of course that raises a few other practicality issues; obviously you still need to be able to configure the Cyclone V for designs that don't have/require a cartridge adapter, and you need some way of updating the bitstream on the adapter should a new version be released. However I don't think they're major issues. Opinions?

The fire control in Penetrator was ground-breaking; takes a little to get used to it but when you do, it's the perfect mechanism to allow fire & bomb with the arrow key layout on the Model I. You could do a lot worse than Cosmic Fighter being your only game too! For those that don't realise, it's a clone of the arcade game Astro Blaster with the usual Big Five Software twist.

There's absolutely no way I could choose two Model I/III games; I used a TRS-80 every single day for 10 years and there's a ton of great games. Starting with a Level I, 4K system I played Flying Saucers, Tandy Invaders and Time Trek to death! Of course every Big Five Software title written by Bill & Jeff was top notch! Computer Shack/Michtron rarely put a foot wrong either, even if 3 of their later games were essentially the same game. Time Bandit was a stand-out from them. Ditto for Adventure International; Eliminator and Donkey Kong examples from them. I especially liked Penetrator, it was an amazing Scramble clone given the capabilities of the machine. Funsoft had Apple Panic. Fun Division had Donut Dilemma. Acorn had several... there's dozens I can't recall now...

Stellar Escort was the first Big Five Software game not programmed by Jeff or Bill and boy, did it show! Nowhere near the level of their earlier games...

Yes! I produced a map of the entire game and printed it on my Epson MX80 - from memory it was about 6-8 sheets wide at its widest. I think I made a BMP file of it on the PC about 2 decades ago... I think I still have the printout but not sure where the BMP is?!? AFAIK you could never finish the game. Not sure if that was the result of the 'crack' or just how the game went. Hey just found it has a Facebook Page by the author! I found his Volcano Hunter web page years ago and emailed him about it but never got a response...

It's been quite a few years since I worked on USB, but IIRC HID operates via Interrupt transfers and unless you can strong-arm the USB host controller the polling is scheduled by the controller at the frequency requested in the endpoint descriptor in the HID device. For low/full speed devices that's minimum 1ms, for high speed it's 125us. I don't know what typical HID devices set as their polling frequency, but the spec allows it to be up to 255 times longer. So as far as I know, you can't synchronise a host interrupt transfer poll to an external event, nor mandate a particular polling frequency, without having some control over the host stack (and possibly breaking the standard in the process).

Great that there's others around still interested and/or dabbling with this stuff! Wow - Space 1999 on the Oric is very, very impressive! I've definitely got to put this on my to-do list! And a bonus that the full source code is available of course So, bearing in mind that my technical knowledge of the Apple II is limited to what Lode Runner needs/does, and that of Oric is what I gleaned from a quick perusal of the Wikipedia page - how are you handling the reduced vertical resolution on the Apple for the Space 1999 port? Oh and for those interested in ports from System X to System Y, make sure you check out Sockmaster's port of the arcade Donkey Kong to the Coco3 - it'll blow your socks off!

First of all, this pretty much describes my dream piece of kit. My only disappointment is that I didn't get to design it myself. Though if you do release this and it is actually called Zimba 3000, I'm not buying one! Something I'd very much like to see on here is the option for a JAMMA interface. Given that the audio/video will be broken out onto a separate video PCB, I'm thinking that extending that to JAMMA would perhaps not impact the main design much at all? Even if you needed a cheap micro on the JAMMA board reading the inputs and spitting them at the FPGA in a SPI stream so you're only using a few extra pins on the FPGA/connector? I guess another option with little-to-no impact on the design would be a cheap USB device chip on the JAMMA board that plugged into one of the main USB ports on the mainboard?

Old topic but pehaps someone is still interested? I'm currently reverse-engineering the original ZX Spectrum (Z80) version of Knight Lore, the ultimate goal being to port it to the TRS-80 Colour Computer 3 (Coco3, 6809). What I should end up with is a fully-commented disassembly of the original code. If that's of use to someone attempting an Apple II port, contact me and we can discuss. I might also be talked into working on the port myself. FWIW I'm also producing a C port of the game, with what should be a platform-independent game core, that I'm hoping to port to a few more capable systems like the Sega Genesis and the Amiga, and possibly the Neo Geo. Knight Lore has a lot of code dedicated to rendering, and spends a lot of time doing so. It has a complete frame buffer that gets copied into video memory each update. The Spectrum doesn't have completely linear video memory either, so there are some addressing hoops to jump through, though perhaps not as many as on the Apple. As for the sprite (object) data - there's a lot of it, about 16K. There's only one copy of each sprite, which is flipped in-place if necessary and then bit-shifted as rendered to the frame buffer, so I guess that's exactly what you'd do on the Apple port to handle the 7-bit graphics memory. Mind you it has a 3.5MHz Z80 pushing all this data around; maybe a tall ask for the Apple's 1MHz 6502? FTR last year I fully reversed-engineered Apple II Lode Runner, and ported it to the Coco3 - a complete and pixel-perfect port of the original; even has the same AI bug! I completely reformatted the graphics and recoded the rendering routines of course, something that would obviously have to be done for Knight Lore on the Apple. I also produced a C version whose AI is not yet fully debugged (almost there). I'm planning Sega Genesis and Amiga ports based on this, but it already runs on the Neo Geo. I've even burned a CD and played it on my NGCD system. Have a dig around my blog for more info... Whilst I have never developed for the Apple II, I've obviously done the reverse, as noted above. I'm also planning on porting a few other Apple II titles, namely Karateka and Prince Of Persia, to other platforms. Would be interested to hear from any others that have plans to port games to/from the Apple or any other system for that matter.

The whole Neo Geo core was a throwaway comment by Mike. Wishful thinking. Pie-in-the-sky stuff. If you want the ability to use legacy cartridges for the core, then obviously your cartridge port will require all 240 pins on the MVS cartridge, or at the very least 200 for the AES. Either way, that's a lot of pins for a multi-system emulator console (and connectors can be frustratingly expensive). Failing that, if you want to run off SD for example, then you need to copy the cartridge data into either 5 parallel memory devices, or a lesser number of devices and time-multiplex access from the Neo Geo core. You also need to remember that complex FPGA cores are still running at sub-100MHz speeds in cheaper devices, so you hit the bandwidth limit pretty quickly when trying to multiplex access to/from external devices. It says something that such a popular system like the Neo Geo, which also tends to have users with open wallets, hasn't yet seen an FPGA core. Not to say it's technical impossible - I've actually had Joy Joy Kid running through the attract mode on an Altera DE2 with just the FIX layer implemented - but certainly doesn't lend itself to prototyping without dedicated hardware.

"made some adjustments to our hardware team" - not "additions" to the hardware team? Sounds like someone has either jumped ship, or been let go!?! "We will also be lowering the price while maintaining most of the cool features you all want." Is this an admission the the 1st design was rubbish? How do you magically reduce the price without losing features? Of course, parting shots of a marketer should be taken with a grain of salt. For me, I think he's done his dash. I wouldn't feel confident that any team he has assembled will produce what they promise. Not saying that won't produce something, but it won't be what they set out to do. I too personally hope that Kevtris doesn't have anything to do with these guys. Only because I can see his work being diluted and nobbled in the process. But I also understand that if someone is throwing money at you for something you've already worked hard for on your own dime, it's difficult to turn your back, especially if it's unlikely to happen again. I'd rather see him produce his own hardware, with him calling the shots, even if that means it won't come in a shiny Jaguar case.

The WTF was "What the Fuck is happening here?", not "What the Fuck are you talking about?" All good! When I posted that response I was thinking that the system had quoted me, but then soon after realised it was actually possible to misquote with careless use of the delete key.

WTF? I never said anything of the sort?!?

Looks like I've been blocked from commenting on the FB page, and all my comments have been deleted. "We value your feedback, as long as you agree with us and don't ask any embarrassing questions." Maybe we should all report the page as a scam?

One of the biggest problems with the whole campaign is that they have no idea what they're designing themselves, nor who the target market are. So you can be forgiven for thinking it will emulate classic systems in the FPGA, and also for thinking that it won't - because both have been either explicitly or implicitly touted over the last few months. For me personally, an FPGA-based console that emulates classic systems is exactly what I'm looking for. OTOH I am completely and utterly disinsterested in an ARM-based console with (or without) software emulation (plenty of those out there already). So to run a campaign that may or not have have an FPGA is, to me, like someone starting up a campaign that may produce an apple, or may produce an orange. No way in hell I'll be even tempted to fund that. And it's pretty clear to me that regardless, the funding level will have very little bearing on what they do actually produce (FPGA or not) given their lack of competence or honesty up until now. "Sorry guys, we were going to stick a big FPGA in there, but we decided it was going to cost too much for no gain, and we've gone in a different direction. But thanks for your pledge, you'll be receiving the product you didn't want in a few weeks."

Hah! But I don't hold that against him at all, I can't help myself either!

Agreed. Nothing but the same old arguments repeated ad nauseum over the last few days. Everyone has their own opinion on why it failed and what needs to change (and I'm guilty of this too) yet there's been very little in the way of new developments, except that video, which has been discected and analysed by all and sundry. My mouse wheel has been getting a real workout recently. From hereon in, it's simply morbid fascination (again, guilty).

The only problem there is that about 7 years go I worked on an FPGA design that mixed two video streams from PC sources, and even added a 3rd from the FPGA itself. Altium (FPGA vendor) even have a video IP suite with a mixer in it. So I hope (for their sake) that's not it either.

To answer each of your questions: Deflection. Because there's nothing else to talk about. You don't need to know about it. To hide that exact fact. No, nothing patentable. Again, deflection. Fan, no fan, it's all air cooled. Again, nothing else to talk about.