|
Post by gtoal on Aug 30, 2017 17:31:48 GMT -5
Some years ago I started a project to clone Tailgunner for the Vectrex. For various reasons I gave up on it at that time, but several things have changed since then, and now I'm retired and have some free time on my hands, I'm picking up where I left off 15 years ago Some background info on what I'm doing is in gtoal.com/vectrex/tailgunner/README.txt and there's preliminary source code to look at in gtoal.com/vectrex/tailgunner/tgvectrex.c.htmlThis code is a translation of some code I wrote in the children's language, "Scratch", so it isn't fully ported yet and doesn't run, but it does go through the "cmoc" compiler for the 6809 and I'm hopeful the resulting code is going to be well within the code and data size limits of the Vectrex. It'll probably take me a week or two to get some running code. I just thought I'ld start throwing out the work-in-progress status in case people have advice for me based on what's planned, so I don't end up rewriting a bunch of stuff because I was unaware of some major limitation until too late! At the moment I'm mostly working on refactoring code to use 8 and 16 bit data, since the code I'm translating from came off a system whose only data type was a very large float! Graham
|
|
|
Post by bob on Aug 31, 2017 7:49:09 GMT -5
Are you aware of the Vectrex32? If not, check it out at Vectrex32.com. It's a 32 bit processor, with a floating point coprocessor, that plugs into the Vectrex's cartridge slot and allows you to write games in interactive interpreted BASIC. It provides fairly high level support for 3D graphics too. It would be a lot easier implementing Tail Gunner on it, than in C. Disclosure: I'm the creator of Vectrex32. - Bob
|
|
|
Post by gtoal on Aug 31, 2017 15:08:24 GMT -5
Are you aware of the Vectrex32? If not, check it out at Vectrex32.com. It's a 32 bit processor, with a floating point coprocessor, that plugs into the Vectrex's cartridge slot and allows you to write games in interactive interpreted BASIC. It provides fairly high level support for 3D graphics too. It would be a lot easier implementing Tail Gunner on it, than in C. Disclosure: I'm the creator of Vectrex32. - Bob I wasn't - thank you for the pointer! However if I just wanted to play tailgunner on a vector screen I would resurrect an old DOS motherboard and use Zonn's Zektor card with it :-) The reason for writing this is so that other Vectrex owners can enjoy playing Tailgunner as much as I do :-) btw as you may have guessed this is an open source project, the game will be free when complete, and if you want to add support for your Vectrex32 system by all means feed me back some diffs. The system dependent part should be fairly self-contained. I'm currently testing using OpenGL on linux, until I've massaged the source down to using only 16 bit ints... Graham
|
|
|
Post by bob on Aug 31, 2017 15:33:16 GMT -5
Correct me if I'm wrong, but I don't think the Zektor card is being made anymore. And if you search for "zektor zvg" on eBay, there are zero hits, versus dozens of hits for "vectrex system". The Zektor card is unobtanium.
The Vectrex32 is a stand-alone cartridge that plugs into a Vectrex and lets you play games on the Vectrex - no PC required. If you write Tail Gunner for the Vectrex32, other Vectrex owners will be able to enjoy it.
- Bob
|
|
|
Post by VectorX on Aug 31, 2017 16:27:27 GMT -5
Correct me if I'm wrong, but I don't think the Zektor card is being made anymore. Right, it hasn't been for years, unfortunately.
|
|
|
Post by gtoal on Aug 31, 2017 19:55:29 GMT -5
Correct me if I'm wrong, but I don't think the Zektor card is being made anymore. And if you search for "zektor zvg" on eBay, there are zero hits, versus dozens of hits for "vectrex system". The Zektor card is unobtanium. The Vectrex32 is a stand-alone cartridge that plugs into a Vectrex and lets you play games on the Vectrex - no PC required. If you write Tail Gunner for the Vectrex32, other Vectrex owners will be able to enjoy it. - Bob Fortunately I got one at the time they were new :-) I also have one of the really early mini-itx format 386 boards that will fit inside the Vectrex case along with the Zektor. I used to run vector mame on it.
|
|
|
Post by gtoal on Sept 3, 2017 15:48:56 GMT -5
I'm making progress with the Tailgunner rewrite. Most of the support components (shields, score, etc) are in place and working, in fact the only big component that I haven't got working yet is the ships themselves. I've finished removing all longs, floats and doubles from the old sources, and have an 8/16 bit program that now compiles successfully using the cmoc compiler. I've done some basic conversion of floats to fixed point, but there's more to do. (sin and cos was easy, I'm still thinking about how to do asin and atan...) I have no idea if it will fit on a Vectrex or run. The object looks to be about 51K and I *think* I'm under 800 bytes of RAM, but I've noticed I can make big changes to the source and the size of the object stays the same, so I'm not sure how much is actual code and how much is alignment or padding in the binary. It would be nice if the compiler reported space usage at the end the way all our compilers used to do back in the 70's... Is there anyone out there who uses C on the Vectrex who would be interested in collaborating on this project? While I am working on the game play, if someone could start implementing the machine-dependent parts to draw vectors on the hardware, that would help a lot! Even if it only runs under emulation at first, just getting an executable binary will be a step forward. At this point it's way too early to worry about speed and optimisations, I just want to get something running and from there I can work out where the bottlenecks are, or if the code is ballpark for the platform and doesn't need major sections to be rewritten. (There are several areas I know about and have commented in the source, that are far from optimal for the Vectrex - due to the history of the program initially being from a raster-based implementation) A snapshot of the source (updated any time I complete some changes) is in gtoal.com/vectrex/tailgunner/tgvectrex.c with a web-readable version in gtoal.com/vectrex/tailgunner/tgvectrex.c.htmlFeel free to grab a copy and play with it. It should already compile and run to some extent on any platform with OpenGL to give you an idea of what to expect. At some point in the distant future I expect to ask for volunteers to take individual modules from the program (such as the star field, or the missiles) and rip them out entirely and replace them with code more suitable for the Vectrex, whether in C and using hardware features such as scaling, or in embedded assembler. Ultimately I know that Tailgunner can fit on a Vectrex and should perform well, it's just a question of the optimal path for us to get there. Graham
|
|
|
Post by gtoal on Sept 3, 2017 16:49:58 GMT -5
What's everyone's experience of using GCC vs CMOC? I had used GCC maybe 20 years ago and it seemed rather ropey at the time, which was an experience that had somewhat put me off from trying it this time round, and it seemed at first glance that the 6809 gcc systems available now were basically just the old ones without much improvement?
cmoc at first appeared to be a good choice as it seems quite solid (and going from it having been written in C++, relatively new), however now I've had a few days to look at the code, I'm seeing that although the code may be correct (which is always a good sign) it is *extremely* verbose - just a quick eyeball of the generated assembler suggests as much as 50 - 100% bloated over the code I would expect to see. Is gcc significantly better?
cmoc does things like promoting all 8 bit values to 16 bits when manipulating them. It's as if it's a 16-bit compiler with some crude hacks retrofitted to add 8 bit data as an afterthought?
It's optimisation strategy appears to be peepholing, yet there are really really obvious optimisations missing.
The worst aspect is the use of registers and the calling conventions. My guess is that the calling conventions are forced by the traditional C feature of being able to omit parameters to a procedure, but that's an antiquated convention that is pretty much only ever used in printf statements nowadays and modern C's have a better way to handle that anyway. Given that cmoc already declares its independence from standard C, it wouldn't have been a great step to say that parameters cannot be omitted, which would let it use more efficient calling conventions. I'm not even talking about passing parameters in registers - just about when and where the stack is adjusted...
Register usage is a bit strange too. It seldom takes advantage of X and Y, and could use S and U better.
I'm pretty sure that by fixing the calling conventions, register usage, and 8/16 bit operations, code size could be halved, never mind actual code optimisations or even improved peepholing. So my question for 6809 C users out there is "have you looked at the output from cmoc and gcc, and is gcc significantly better to the extent that it is worth living with and coding around any old code generation glitches?"
(I *really* do not want to take a year out from this project now I have it going again, to write a better C compiler, tempting as that prospect is! :-) I'm getting too old for this ... )
Graham
|
|
|
Post by Malban on Sept 3, 2017 17:46:02 GMT -5
Hi, since I had a coding weekend of my own I haven't been able to look any closer to what you discussed above (or via email :-) ). Only thing I am thinking of is the 51k barrier you mentioned. That reeks (if not stinks :-) ) that somewhere the compiler thinks of the RAM adresses as of ROM. Perhaps there are some switches or configurations for vectrex you overlooked in the cmoc setup? Somewhere one can configure $c800 upwards as RAM (BSS). $c800 = 51200! I have watched similar behavour with gcc compliled sourced from Peer's students (look at: vectorgaming.proboards.com/thread/1685/vectrex-programming-german-university) Regards Malban
|
|
|
Post by gtoal on Sept 4, 2017 15:44:42 GMT -5
I've finished removing all longs, floats and doubles from the old sources, and have an 8/16 bit program that now compiles successfully using the cmoc compiler. I've done some basic conversion of floats to fixed point, but there's more to do. (sin and cos was easy, I'm still thinking about how to do asin and atan...) I've added asin and atan code that approximates the values returned by Scratch's internal versions, with accuracy that is good enough for a video game (though I wouldn't use them elsewhere such as in a drone controller!). So that is the last of the missing code in place, all I have to do now is get it to run :-) (That's *not* the easy bit...) G
|
|
|
Post by bob on Sept 5, 2017 9:24:59 GMT -5
FYI, I'm offering a cash bounty for a Tail Gunner game on the Vectrex32. This was not prompted by your post about working on Tail Gunner, so it's not intended to step on your toes; I've been planning this for a while and I always expected to announce it after Labor Day in the US (the unofficial end of summer). You can see the details at vectrex32.com/the-v-prize. - Bob
|
|
|
Post by gtoal on Sept 5, 2017 14:52:29 GMT -5
FYI, I'm offering a cash bounty for a Tail Gunner game on the Vectrex32. This was not prompted by your post about working on Tail Gunner, so it's not intended to step on your toes; I've been planning this for a while and I always expected to announce it after Labor Day in the US (the unofficial end of summer). You can see the details at vectrex32.com/the-v-prize. - Bob Cool! I'm not going to enter myself, since I'm doing this anyway (and you're looking for entries in BASIC), but I hope you'll allow anyone who wants to, to use any parts of this code in their program if they want. That'll save people development time (especially the vectors for the ships, which Peter Hirschberg hand-coded for me some years ago), and it'll help me by feeding back game play improvements into my implementation if they keep the basic structure intact. I've kept the C that I write in pretty simple, so it ought to convert to BASIC without much difficulty - maybe even be machine-translatable if your version of BASIC is compatible with the subset of C that I use... I have a background project of writing a subset C compiler, so sometimes I deliberately code projects in that subset of C so that they can be used as test code for my compiler... this one should be close to that standard - no structs, for example - structs are simulated using integer arrays... and no pointers; and all procedure parameters are by value. There are not even any functions - results are passed via global variables... it may be poor coding style but it's tremendously helpful when you want to do something with the code ... such as translate it into basic (or even into hand assembly...) Of course I have to get mine working first To which end, I'm pleased to relate that I got the ship display working last night. I have some tweaking to do concerning positioning and getting the perspective right, but that's minor compared to the big hurdle of getting the ships on screen at all with rotation. Graham
|
|
|
Post by gtoal on Sept 5, 2017 18:01:33 GMT -5
Sept 3, 2017 17:46:02 GMT -5 Malban said:
I no longer think size is going to be an issue:
CODE+CONSTS: 0000-27E8 DATA: C880-CB28
Code is under 10K and ram usage is under 700 bytes. Looks like it will fit nicely.
*** UPDATE... I ripped out the entire starfield code and replaced it with something much simpler, and now the RAM takes up C880-C9AF :-)
|
|
|
Post by Malban on Sept 6, 2017 2:43:59 GMT -5
Gz!
Since I am always hopping from one programming idea to the next anyway, I thought I might try (the long time brewing ...) to do the Vide "C" part.
Yesterday I had tentive steps for Vide to support "C". On my Mac (after much fiddlestick research to get going) I compiled the gcc6809 and the editor in Vide has now a menu entry "compile C". Which actually works (on Mac only as of now). I got the entire tool chain working, but...
I think I will only use the compiler and do the assembling and linking Vide internally. That way I can use (obviously) the internal assembler and thus use all debugging features I have anyway.
So - I now am messing with sorting out linking/library handling on my own. But first steps are taken. Once I am able to produce my first bin in Vide (from C-sources) - I'll give your code a go...
Malban
|
|
|
Post by gtoal on Sept 6, 2017 10:04:50 GMT -5
Gz! Since I am always hopping from one programming idea to the next anyway, I thought I might try (the long time brewing ...) to do the Vide "C" part. Yesterday I had tentive steps for Vide to support "C". On my Mac (after much fiddlestick research to get going) I compiled the gcc6809 and the editor in Vide has now a menu entry "compile C". Which actually works (on Mac only as of now). I got the entire tool chain working, but... Good show! If you're looking for more C to test with... this Asteroids clone seems pretty portable - I bet it wouldn't take much to get going on the Vectrex... www.newbreedsoftware.com/agendaroids/download/ (Though obviously I'm looking forward to seeing what you do with Tailgunner first. I've updated gtoal.com/vectrex/tailgunner/tgvectrex.c with last night's mods. It's not playable yet but it runs and it looks like most of the pieces are now present with just some debugging to do ... (I plan to rip & replace the missile code sometime, but getting the ship mechanics correct is obviously a higher priority) (Btw you may be amused (or not) to know I've had a Vide program out there for some years. It's a screen editor based on a command-line editor called Ecce. I doubt that will cause a problem for you! - apparently it didn't for these people :-() G
|
|