|
Post by D-Type on Nov 12, 2017 8:56:41 GMT -5
I also thought that it might be possible to use the free areas in the address space, but I've not looked into the actual address decoding closely enough.
It's a nice clean idea, though, if it works, I'd go for that over bank switching, you'd need extra hardware either way in a physical cart. It's then up to the emulator authors to emulate it if they feel like it :-)
Emulators can handle a bank switch design, but when I looked around for the circuit design, I couldn't find anything obvious.
It's it documented anywhere? I guess I could have a look at the source code of at emulator.
|
|
|
Post by gtoal on Nov 12, 2017 19:46:10 GMT -5
It's not so much that I feel the need to design a new cartridge for this one game, it's more that while I was looking into the problem I discovered that for reasons that totally escape me, *no-one* has ever built what to me is the obvious cartridge - the one that takes advantage of how the memory areas are positioned and which has the signals available on the edge connector - and therefor seems to be what the original designers probably expected to eventually use as expansion path...
So although, yes, I *can* take advantage of this for Tailgunner, it's now become a thing in itself which I find interesting and want to do, and since I want to do it anyway, I might as well use Tailgunner as the first test and example...
I don't actually know yet if I *need* to go beyond 32K - although the ROM is close already, when I throw away the vector descriptions of the ships which I will no longer need, and throw away the 3D projection code which I won't be using any more, and reduce the number of frames after running tests to see how few are still acceptable... then I *might* be able to fit it in 32K - but I won't know any of that until I've finished generating those pre-rendered vector lists first, which is what I've been working on these last few weeks.
It's tricky because the original vectors are in a 1K scale range and have to be reduced - but since Vectrex vectors are relative rather than absolute, it's not a simple scaling factor - you want to scale the *relative* vectors to their maximum size (which means -128..127 with an x,y offset for the center of the sprite) and then determine a scaling parameter for that single frame to reduce it back to the appropriate physical size on screen. Which means a drawing routine with x,y,scale,vectors as parameters... lots of code still to write!
Anyway, I appreciate your advice but I still intend to have a go at building a 48K cart - for the fun of it, not because I need it! I'ld like to think that once I have proven the principle, everyone else might see reason and realise that the Vectrex is *meant* to default to 48K cartridges, and these 32K carts have been a weird aberration! :-)
(Note that there's no reason you couldn't apply bankswitching to 48K cartridges as well - either all 48K at once or a 16K or 32K subset, leaving the remaining ROM resident and shared...)
G
|
|
|
Post by gtoal on Nov 13, 2017 4:05:41 GMT -5
I got the first ship flying tonight :-)
It looks exactly like the real game (since it is extracted from the real game). One ship is currently using about 1/4 of the 30,000 available cycles, so 3 ships will work - though it might be a squeeze with the stars and the crosshair and the missiles. But that is with relatively crude code and BIOS routines - so it is 100% certain that using the optimised coding tricks of people like Malban and Tomas Sontowski will make this run at an acceptable speed :-)
However to get that one ship and single flightpath recording to fit, I had to delete various components of the game, so some sort of extended ROM (whether flat space or bankswitched) is definitely now a necessity.
Even if I find my old Hutchinson Vecram, it's no longer a workable solution, so until I get some better hardware to test on, I think I have to postpone my target release date of Christmas :-(
Nevertheless, I'm pumped about getting ships to fly.
3am. Time for bed now.
G
|
|
|
Post by Mayhem on Nov 13, 2017 6:32:10 GMT -5
Well, if the design of a new cartridge is linked with the production of the game, then keep on posting, it's still interesting to me So yes, I misconstrued the nature of the hardware post there, the attempt is to make a 48k memory bank instead of the default 32k that everyone has been using since the beginning.
|
|
|
Post by gtoal on Nov 13, 2017 11:12:11 GMT -5
Hi guys! Here's the new demo with a ship for you to try... gtoal.com/vectrex/tailgunner/main.binIt just loops the intro banner and then a ship. (Unless you press the coin/start buttons in which case I guess it will be stuck looping the ship forever!) G
|
|
|
Post by thomas on Nov 13, 2017 11:19:35 GMT -5
I second Malbans comments that using a custom cartridge for 48K just so you don't need to 'bank switch' might be considered a bit over the top. And inelegant. R.A and Core are 64k so I do know that it adds another level of complication during development. Mostly it's just tedious, not much fun. In the end we are talking about a single bit you need to fiddle around with. Nevertheless, if that's what you are going for it's straightforward for me to add another bus emulation scheme to allow to run this typ of cart. on a VecFever. I am wondering what'll happen once you run over the 48k limit, though.. gtoal: if you are interested in a VecFever for development please do contact me - that's what it was designed for..
|
|
|
Post by VectorX on Nov 13, 2017 11:38:39 GMT -5
I second Malbans comments that using a custom cartridge for 48K just so you don't need to 'bank switch' might be considered a bit over the top. And inelegant. R.A and Core are 64k so I do know that it adds another level of complication during development. Mostly it's just tedious, not much fun. In the end we are talking about a single bit you need to fiddle around with. He might do another project at some point so he could end up using it again.
|
|
|
Post by Malban on Nov 13, 2017 12:02:29 GMT -5
Pssst Thomas!
If you make those statements publically - all kinds of people will start developing for Vectrex!
:-)
Malban
|
|
|
Post by VectorX on Nov 13, 2017 12:40:16 GMT -5
^Oh no, like we don't have enough already to keep us happy!
|
|
|
Post by gtoal on Nov 13, 2017 17:58:22 GMT -5
He might do another project at some point so he could end up using it again. I do have another game sitting in the aisles waiting to be written, but I am not going to touch it until Tailgunner is complete. I am determined to finish it this time - it's been a failing of mine in the past that I've let myself get sidetracked, which I am not going to allow myself to do this time. (but since I mentioned it... it will look a little like scratch.mit.edu/projects/131676740/ or scratch.mit.edu/projects/103091739/ and will use layouts generated on the fly with this algorithm that I wrote in Scratch some time ago: scratch.mit.edu/projects/143657513/ - with luck I may be able to appropriate some of the Bloxorz graphics code... However I'm never proprietary about code so if anyone has a look at those links and feels they want to have a go at it themselves, be my guest! As long as it gets done in the end I don't care who does it. Indeed, same applies to tailgunner, if people want to work on it, that's why I put my source code out there... ) btw the tailgunner source code is somewhat in disarray at the moment and a bit embarrassing to be seen, but it *is* up to date and reflects what is in the binary. I'm quite serious about programming in public view, warts and all. It'll be prettier again once I've got over the 32K hump (and probably removed the vestigial CMOC support - I was keeping my options open until I'd had time to evaluate the current gcc incarnation. I've decided it's OK, with minor caveats.). G
|
|
|
Post by kokovec on Nov 14, 2017 3:24:38 GMT -5
Hey Malban... everything you say is true. Bank switching is the way to go and you get 64K of ROM. The only advantage of extending past 32K space is to add RAM (in the 8000-C7FF space). That extra 17K of RAM can come in really handy. But then you're back in designing a special cartridge. Like my old man used to say.. "Erst denken, dann handeln" Usually followed up by a proper "Dummkopf!" I always deserved it.
|
|
|
Post by gtoal on Nov 14, 2017 4:24:19 GMT -5
I have (a little bit of) good news, but mainly bad news and more bad news. First the good news. Malban's modification of the Vide emulator to support 48K cartridges worked. I can compile Tailgunner with all the features restored and a ship, and the 33K rom loads and executes. Now the slightly bad news and then the worse news :-( ... 1) the recorded ship vectors are not being animated - but it's late, I'm tired, and until I spend some time on it, I don't know if it's the new emulation or if - more likely - I broke something when I just now removed a lot of unused code from the source to clean it up. (All the trig for ship rendering that isn't going to be used now I've made the decision to pre-render ships instead). But given what comes next, I probably won't even bother trying to debug it, because... 2) finally being able to measure it, the recorded vectors for a single ship and one flight path take up about 10K. At best I can reduce that by maybe 1/3rd with a lot of effort. Not a solution - there are 4 ship types and to make the game playable, you probably want at least 5 different styles of attack wave and each attack wave uses 3 ships. That's maybe 10 * 5 * 3 = 150K of vectors, naively. Not even ball-park. So recording the complete vector display and just replaying it is not going to work. On to plan B. I have to pre-render the ships at each orientation that they may be displayed, and record (or generate) flightpaths using only x,y, scale, and image index. Doable, but much much more programming work than Plan A had been, and really puts the kybosh on a Christmas release The test attack wave was a recording of 126 images in 10K so with the space available that means I have O(300) pre-rendered stored images available. That ought to be enough using Plan B. I haven't given up yet! G
|
|
|
Post by Malban on Nov 14, 2017 4:40:46 GMT -5
If you insist on completely pre rendered flight paths - perhaps a packer/unpacker might come handy? I know it will generate additional cycle overhead...
But the difference between two frames are possibly not all that big, playing additionaly with scale factors for "zooming", perhaps "streamed" unpacking of some sort might be feasable?
-
Or... calculate the flightpath... record only every 10th (or so) vectorlist and do "morph steps" between thos recorded frames...
...
Malban
|
|
|
Post by D-Type on Nov 14, 2017 6:52:06 GMT -5
That extra 17K of RAM can come in really handy. Now that's an interesting point, the program I'm thinking about is OK (for now) with 32k ROM, but the limited RAM is probably going to be an issue, putting in that free slot might be a great solution. I'd need to create a custom cartridge anyway so adding RAM and some address decoding would be OK, although I'm pretty sure a VecFever could also do what I need regarding emulation of the RAM!
|
|
|
Post by Malban on Nov 14, 2017 9:33:26 GMT -5
The reason your current Tailgunner is not working correctly is a bug in Vide. I'll fix it tonight.
Malban
|
|