|
|
Post by Peer on Nov 17, 2023 0:43:08 GMT -5
I use Vide to disassemble the binaries. The difficulty here is figuring out which parts of the assembly code are instructions, and which are data. The result is an undocumented piece of machine code. You can use MAME to separate code and data for a binary, ~98% accurate and should take maybe 1 hour to complete. YouTube Vic-20 MAME DebuggerTwo minute video shows 6502 code, but works equally well for Vectrex 6809, I've tried it. For my disassembler, you end up with a file like this (Vic-20 + 8k expansion): data 2000-3fff
; ----------------
code 201c-20ad
code 2079-20f2
code 20f7-216a
code 2173-2204
code 220f-22e8
code 22ed-22f7
...
etc.
To get a VECTREX binary (vectrex.bin) to run in MAME, here's the Windows command line I used (paths might need tweaking, you need to provide .\vectrex\exec_rom.bin, you don't need -natural, I use it as I have a Dvorak keyboard): mame vectrex vectrex -swpath .\vectrex.bin -rompath . -debug -debugger_font_size 9 -natural -nomaxI should rephrase. The really difficult (and interesting) part rather is figuring out the semantics of the data and the code. With some experience, telling data from code, works quite well, and you are correct, there are also tools which help in this regard. I have tried some of them. Recently, I tried Ghidra, which I find quite promising. But my weapon of choice is and will likely always be Vide (hope you read this, Malban), along with some custom scripts I wrote. And whenever I miss a feature in Vide, Malban is more than helpful and implements it. Spinball was particularly easy in this regard. The binary is 8K, of which the first 5K are code, and the remaining 3K are data. Strictly separated. But the data itself is a maze of mazes. Tables of pointers to tables of data lists containing pointers to tables of pointers to lists of addresses of packets containing vectors and other data. And I am not exaggerating. The vector format for some objects is none of the typical Vectrex vector formats. And collision check data is stored in between vector data. And parts of what is actually to be drawn are not stored in ROM, but computed on the fly in RAM. Quite amazing. The framerate is pretty bad. Drawing just the playfield takes almost 30000 cycles, and computing the ball movements almost another 15000 cycles. I have some vage guesses about the overall code design by now, but there is still a lot I do not yet understand. |
|
|
|
Post by D-Type on Nov 17, 2023 3:33:31 GMT -5
I should rephrase. The really difficult (and interesting) part rather is figuring out the semantics of the data and the code. With some experience, telling data from code, works quite well, and you are correct, there are also tools which help in this regard. I have tried some of them. Recently, I tried Ghidra, which I find quite promising. But my weapon of choice is and will likely always be Vide (hope you read this, Malban ), along with some custom scripts I wrote. And whenever I miss a feature in Vide, Malban is more than helpful and implements it. Yes, that is the interesting bit, but none of the tools I've tried really do a good job of separating the code and data, and it just gets in the way and slows you down when doing the code analysis, so doing a MAME Debugger code trace is an efficiency no-brainer for me. I've always steered clear of Ghidra because it's such a big install and I don't really like the UI experience of Java apps, but nearing the end of the Jetpac reverse engineering, these are some big subroutines that are really difficult to get your head around in a linear code fashion, I've ended up making a big flowcharts on paper to understand them. So, I decided to dive in to use Ghidra's function graph (i.e. a flowchart) tool to document those parts. It's not as straightforward as I'd like, Ghidra is a big program, setting it all up is awkward, then you have to import all your existing disassembly work using Python scripts etc., but the resulting flowcharts are excellent! Another problem is it doesn't use textfiles for your project, so you can't (sensibly) use git for source control. You mentioned using VIDE in a previous post and I forgot to respond to it  , sorry, but you are right, it's probably the most productive single tool for Vectrex games due to its function knowledge and, especially, integration with the emulator. Indeed, my VecForth cross-compiler outputs a VIDE .cnt file so that you can see all the Forth dictionary words and virtual machine config in the VIDE debugger, works great! When my 6502 reverse engineering with Ghidra is done (it's been over a year now), my plan is to return to my previous Vectrex project, which you already know about. I really want to go back to it now, but I don't like leaving things unfinished and the 6502 work isn't done until the Ghidra stuff is completed. Spinball was particularly easy in this regard. The binary is 8K, of which the first 5K are code, and the remaining 3K are data. Strictly separated. But the data itself is a maze of mazes. Tables of pointers to tables of data lists containing pointers to tables of pointers to lists of addresses of packets containing vectors and other data. And I am not exaggerating. The vector format for some objects is none of the typical Vectrex vector formats. And collision check data is stored in between vector data. And parts of what is actually to be drawn are not stored in ROM, but computed on the fly in RAM. Quite amazing. The framerate is pretty bad. Drawing just the playfield takes almost 30000 cycles, and computing the ball movements almost another 15000 cycles. I have some vage guesses about the overall code design by now, but there is still a lot I do not yet understand. Spinball sounds like an interesting challenge, especially working out the physics. I always thought a pool game would be fun on a Vectrex, you could make it very smooth and maybe zoom the display in and out. Seeing Tee Time reminded me again, though the physics for that are very simple, multiple moving objects would be more challenging. Viewing data structures is another place where MAME has a useful feature, you can open up multiple live memory hex dump windows, each with an arbitrary number of columns, so, if a vectorlist format was 5 characters per line, you could open a memory hex view with 5 columns. I don't think VIDE can do that, that would be a great new feature! (MAME can also display as 8/16/24/32 bit words and in reverse order, which is great for little-endian 6502.) With many of these old games, I wonder how much better they could be with a conversion to SmartList drawing routines, probably wouldn't be hard to do, ROM space isn't really an issue now and getting frame rate under 30,000 would be beautiful in some cases. You might even get some down under 25,000, so everyone could have wobble-free display! |
|
|
|
Post by Peer on Nov 17, 2023 13:28:45 GMT -5
When my 6502 reverse engineering with Ghidra is done (it's been over a year now), my plan is to return to my previous Vectrex project, which you already know about. I really want to go back to it now, but I don't like leaving things unfinished and the 6502 work isn't done until the Ghidra stuff is completed. Cool, I look forward to seeing that project advance! Please keep me posted on your progress. |
|
|
|
Post by fruktodlaren on Nov 20, 2023 12:32:20 GMT -5
Reading your conversation about a subject that is conceptually familiar to me but on a level so deep that I fail to grasp the red thread, was entertaining.
So Peer, would you say Flipper Pinball / Spinball was programmed in a rush or are the maze of data more due to the limitations of the vectrex environment itself? Hypotetically if you would unravel those lists pointing to lists of lists and reorder it in a more efficient data structure, would that help the framerate at all?
Could it be that they put the collision data in between the vector data so they would always be "half there" when needing it so to speak, or is the mess more of a badly arranged workbench where you have to lift things to find what you need?
Might I also remind you to speak to me like I am three years old when replying, please. I am a knowledgeable in mechanics but not programming even though I know enough nomenclature to uphold a conversation about it and maintain the illusion that I understand what is being spoken about.
|
|
|
|
Post by 50tbrd on Nov 20, 2023 13:26:06 GMT -5
I've heard that sometimes its easier to start from scratch than try to fix some of the old games or make a lot of changes.
|
|
|
|
Post by Peer on Nov 20, 2023 13:31:48 GMT -5
Might I also remind you to speak to me like I am three years old when replying, please. I am a knowledgeable in mechanics but not programming even though I know enough nomenclature to uphold a conversation about it and maintain the illusion that I understand what is being spoken about. I am truly sorry if I said anything confusing or sounded overly complicated. I certainly did not mean to write in a condescending way or with excess use of terminology. Sincere apologies if I did.
I will happily answer all questions and try to explain things in a better way. Give me half an hour, as there is some other urgent matter on my desk right now. I will be back and address the "maze" stuff then.
|
|
|
|
Post by Peer on Nov 20, 2023 14:29:57 GMT -5
So Peer, would you say Flipper Pinball / Spinball was programmed in a rush or are the maze of data more due to the limitations of the vectrex environment itself? Hypotetically if you would unravel those lists pointing to lists of lists and reorder it in a more efficient data structure, would that help the framerate at all? Could it be that they put the collision data in between the vector data so they would always be "half there" when needing it so to speak, or is the mess more of a badly arranged workbench where you have to lift things to find what you need? No, on the contrary. I would say that Spinball is a very well written and very well designed piece of software.
Deciphering that large 3K bulk of data-bytes felt like walking through a maze. From the inside, a maze is confusing. But when looked at from the top, the structure of the maze becomes clear. The "Spinball data maze" is well structured. Those lists pointing to lists etc. is not chaos, but the way the programmer organized the stuff which is needed to draw the playfield and to do the trajectory computation of the ball. So to speak it is a very sophisticated way to bundle the necessary data.
And you are correct, vector data and collision-specific data is indeed mixed. The vector lists contain not only vectors, but also pointers (references) to the addresses of the corresponding collision-check information of each vector. This collision-check data then itself contains pointers to information about how the ball is to be reflected on collision.
There is nothing bad about such a design. It is one way to do it. There are certainly other ways, but this is how they did it.
The low framerate, in my opinion, is not primarily a consequence of this data design, but rather of the fact that there is some heavy math going on. There are lots of mathematical subroutines, which are used to compute the trajectory of the ball, and which are computationally expensive. Again, not because they are badly programmed, but simply because they tried to make their mathematical model as accurate as possible. Despite the "bounciness" of the ball, I think they did a really good job here.
I hope this helps. More on the "bounciness" at some other time. Also more on "drawing the playfield" then.
I will cross-post this text in the Spinball thread, and I suggest that we continue our discussion there.
Many Cheers, Peer
|
|
|
|
Post by Peer on Nov 20, 2023 14:38:34 GMT -5
I've heard that sometimes its easier to start from scratch than try to fix some of the old games or make a lot of changes. You are certainly right about that. But as for now, I am not planning to fix or to rewrite Spinball. I only became interested in how Spinball was programmed, while playing it during Vector War. I am analyzing the code out of pure curiosity, and I doubt that there is an easy fix for the "bounciness" of the ball. |
|
|
|
Post by 50tbrd on Nov 20, 2023 15:49:27 GMT -5
I've never really had any aversion to Spinball. I like it for what it is. Any problem I have with Spinball, I also have with any pinball game - They're as much luck as skill. There are spots that the ball can fall that you can't defend.
I'm always really impressed with what the original programmers did with the extreme limitations they were under, especially 4K memory (though a few were 8K). Recently, I was looking at the number of objects Spinball and Clean Sweep draw and its no wonder they have flicker.
|
|
|
|
Post by Peer on Nov 20, 2023 16:09:28 GMT -5
… I'm always really impressed with what the original programmers did with the extreme limitations they were under, especially 4K memory (though a few were 8K) … I absolutely agree. And they had another limitation compared to today's Vectrex developers. We have emulators, running on the same computers we use for coding. Our compilers are fast. Assembling code, generating a binary, and starting it in an emulator to test it, takes a few seconds. Back in the 80s, the compilers were definitely slower. In order to test their code, they had to burn the binary to an EPROM cartridge, put that into a real console, and turn it on to play. The turn-around time for changing a few lines of code and testing the effects, today is seconds, while for them it must have been several minutes. |
|
|
|
Post by fruktodlaren on Nov 21, 2023 14:04:33 GMT -5
Might I also remind you to speak to me like I am three years old when replying, please. I am a knowledgeable in mechanics but not programming even though I know enough nomenclature to uphold a conversation about it and maintain the illusion that I understand what is being spoken about. I am truly sorry if I said anything confusing or sounded overly complicated. I certainly did not mean to write in a condescending way or with excess use of terminology. Sincere apologies if I did. I will happily answer all questions and try to explain things in a better way. Give me half an hour, as there is some other urgent matter on my desk right now. I will be back and address the "maze" stuff then.
You misread my reply. I meant that your reply to THAT question NEEDED to be like directed to a three year old, as my understanding of programming kind of stays at knowing a few fancy words enough to uphold a hollow conversation. |
|
|
|
Post by fruktodlaren on Nov 23, 2023 1:56:04 GMT -5
The two prizes that were in my care at the start of the competition has now been mailed since some time actually.
Those that I played with on my vectrex during this competition all had fun and will for sure return next year.
Len and Moyu could even be considered veterans soon.
|
|
|
|
Post by 8-Bit Waves on Nov 24, 2023 18:20:47 GMT -5
MooMcCowson received his wooden spoon prize. Thank you, Tony!
|
|
|
|
Post by hcmffm on Nov 25, 2023 4:25:20 GMT -5
MooMcCowson received his wooden spoon prize. Thank you, Tony! Thank you for this info, Nathan, and thank you Tony for fast shipping. Please make sure that MooMcCowson eats Köttbullar or other Swedish food at least once a week using the wooden spoon.  |
|
|
|
Post by hcmffm on Nov 25, 2023 11:58:59 GMT -5
All time winners and medal table (click once or twice to enlarge):  |
|
, sorry, but you are right, it's probably the most productive single tool for Vectrex games due to its function knowledge and, especially, integration with the emulator. Indeed, my VecForth cross-compiler outputs a VIDE .cnt file so that you can see all the Forth dictionary words and virtual machine config in the VIDE debugger, works great!
