Do you use any ROM routines?

[garryg]

I was just wondering if any of you Machine Code programers out ther use any of the built in ROM routines, and if so which ones?

Starting out I, think obviously, used the built in drawing routines, but never looked at any of the collision, high score, or most other built in ROM functions.

I'm assuming most, if not all, the origonal Vectrex catalogue releases were written to use the routines.

So what, if any, do you use now?

[kokovec]

For some of my work I use mostly the built-in ROM routines.
I do use some of Malban's raster and animation routines though.
I believe Hyperchase uses a custom drawing routine to create curved lines for the road animation.

[garryg]

I usually concentrate on making the bulk of my code flow through branch statements, with a few jumps as possible.
if using the ROM routines that adds a lot of jumps.


I was thinking of doing a smaller game using as much ROM routines as I can just to see how it goes, and to learn how to use them.

[Peer]

Hi there,

you specifically addressed machine code programmers in your initial question, so I probably do not qualify to answer here as I code(d) all my projects in C and leave the machine code generation to gcc6809. I am using the BIOS functions all over the place in my code, and all I can say is that they work quite well for my purposes. I also tested and tried almost all of them at some point when I was designing my C setup. The penalties for using subroutine jump instructions (jsr + rts) are really negligible if the rest of your algorithms and code is well designed.

I heavily use the BIOS drawing routines, the joystick/button routines, the BIOS syncing, the BIOS sound routines (to a certain degree), and also the BIOS collision detection, and some other stuff. Works quite nicely for me, and I never had any compatibility issues when running the binaries on different real Vectrex console and on different BIOS versions. Overall, I think the designers did quite a good job when they put together the BIOS (though there is also some weird stuff in the BIOS).

It might be of interest to list here some BIOS routines, which I do not use, and why:

• random number generation: the numbers generated by the BIOS routines are of poor (pseudo random) quality, writing one’s own LSFR producing better quality numbers is rather easy (many examples can be found on the net), and likely also the performance will be better
• vector (list) rotation routines: on-the-fly rotation is slow, look-up tables are much faster (if enough rom space is available for those)
• trigonometry routines: if a resolution of 5 degree angles (64 different angle positions) is sufficient, then those BIOS routines can be of some use, but I needed a finer resolution and prefer to code my own specific lookup tables to have more flexibility.
• ...
  

Probably more things worth mentioning which I cannot think of right now.

Cheers,
Peer

[gauze]

since RUM sourcecode is out there, I basically stole a lot of the routines and inlined them in macros to save the 13 cycles for jsr/rts. I use jsr Wait_Recal once per frame as-is though

[minsoft]

I'm a novice working on my first game, so I make use of lots of BIOS routines, for moving/drawing (Moveto_d, Draw_VLc, Print_Str), inputs (Read_Btns, Joy_Digital), collision (Obj_Hit), scoring (Clear_Score, Add_Score_a, New_High_Score),

Over time I have replaced several of them with either straight macro versions (to save the JSR/RTS cycles) or optimised versions (eg Malban's macro version of Draw_VLc). Also I have made other modifications to some, either to save cycles or to do things differently. eg my version of Add_Score_a doesn't strip the leading zeroes, as I want to display them.

I'm sure some of the BIOS routines I use could be optimised more, but some seem to be pretty good...for example I wrote a collision routine of my own (badly) and it used more cycles than Obj_Hit so ended up sticking with Obj_Hit!

While we do not have such limited ROM space these days, if you wanted to make something like a 4K game then it's worth checking out the BIOS routines. That would actually be quite a nice project I think, making a small game that looks & feels like it could have been one of the original releases.

[garryg]

That was my plan, to make a smaller game, based on a really old arcade game, using as much of the original BIOS routines as I can.
I think I've always written my own hi-score and hit routines from my very first test program, and I've wrote demo code that plays with a fair bit of the rest of the BIOS at some point. As long as you draw big and scale small the BIOS drawing routines aren't that bad if you don't try to push it.

[Peer]

Jul 28, 2021 15:15:03 GMT -5 garryg said:

... As long as you draw big and scale small the BIOS drawing routines aren't that bad if you don't try to push it.

Yes, that is what I experienced, too. I also use the BIOS collision detection a lot, as it serves my purposes very well and (so far) is faster than all my previuous attempts to write an own version in C.

Trivia:

In my 2018 Vectrex Academy Class, one student set himself the goal to fit his C project in a 4K binary, and the result was a nice racing game called "YARG". Unfortunately, the web site is not up anymore, but you can still play it in here: YARG

Cheers,

Peer