Spectrum Computing

I think it's because those files are just the functions to draw vectors and output to the screen. Currently, because you have the output.txt first that gets compiled to the first address you org'd at and that clears the screen to black and then returns. You need some code to call those functions in ...

It's a macro, from this file https://github.com/breakintoprogram/lib ... macros.z80

I had two games with my speccy. Mikrogen Space Zombies and I forget the other. Space Zombies didn't even work correctly, the ship would move left by itself randomly.

Congratulations Tom.
I'm looking forward to seeing how you and dr beep got your code size so low.

That may be some kind of Newton Raphson approximation I guess? I've not seen that before and some info about it would be good, to see where the worst case approximations occur. EDIT: Probably a Taylor Series approx instead? Probably needs an else though maybe largest + (smallest>>1) - (smallest>>3)...

A hacky way of getting this distance between two 2d points is this determine largest and smallest values from x,y length = largest + (smallest>>1) gives a worst case 12% error if smallest >= (largest>>3) then length = largest + (smallest>>1) - (largest>>3) gives worst case ~6% error but mostly <2%

Thanks Dr Beep, I'll send it through tonight.

Yeah, should be element = (element >> 1) ^ mask; I guess their typewriters didn't have the xor symbol

I've also realised there's more than the three pages I originally photocopied in the full article.

ParadigmShifter wrote: ↑Sat Mar 30, 2024 9:05 am Yeah. Spin always hangs after recording a GIF so consider yourself lucky

I only remembered to whack up the emulator speed to 500% after a bit... BASIC sucks etc.

I love the ones that look like liquid falling down the screen.

I've had this tatty old photocopy of an old Dr Dobbs article for decades which had a really nice way of doing digital dissolves. I found an online copy of it here https://archive.org/details/1986-11-dr-dobbs-journal/page/48/mode/2up It's the Galois LFSR which is on the wikipedia page in the WOS thre...

I'm no expert, but just looking at the pictures of the board on Bytedelight and the Github page above, it looks like the Byte delight has composite out and a video out while the github one has just video out and a kempston joystick port (from reading the features) I'm going to build a 128K from Byte...

As ParadigmShifter said, you're jumping too far ahead if the first key isn't pressed. I think you would find it easier if you moved the three parts of your code into seperate functions. Like below. Then when you add IncreaseY and DecreaseY it will be simple to understand the flow of your code. ; ; R...

I tend to use 24576/$6000. If you aren't using rom routines or anything that needs the sysvars I guess you could use that memory for buffers once the game has loaded.

It looks like a stack crash, some code got caught in an infinite loop and is PUSHing the same six bytes onto the stack over and over.

It's here on ebay, If it's not in the database might be worth buying. https://www.ebay.co.uk/itm/175767531437?itmmeta=01HQ8FVF6AM35HGTRJZ5MTS7Y5&hash=item28ec8fafad:g:GnAAAOSwHNpkDOrc&itmprp=enc%3AAQAIAAAA4PuO1E95ylXW9mUtzE2QsCkiq4JZHIcXzAjDUcT9lFf7l4%2FlsfXDMVGKQaACfa0kjSLxaxiYIBoOLoWOu0D%2...

Charts for the same month from Your Sinclair, lookslike it might be Rally Driver

ULA A14-15 are the same as the Z80, ~0v

ULA A0-A6 are ~3.6v

Thanks for the checklist. Checked all those voltages and currents and they match. 0v was about 0.2v but that's probably fine. Without the Z80 and ULA, I measured the V on the A0-A15 and D0-D7. A lines were all 0v on the Z80 and ~3.6v on the ULA. All the D lines were 4.9v. The KB lines on the ULA wer...

If none of this finds the problem, with ULA, Z80 and TR3 still removed, power up the board and measure the voltages at all three of the transistors terminals, ULA pin 32 and Z80 pin 6, Then, switch to the 200mA current range on your multimeter. Connect it between the Z80 pin 6 and the transistor em...

16bit code uses two bytes per instruction (minimum) compared to one byte in 8bit, so code size would increase just for that reason. Additionally 16bit games have more complicated gameplay logic and resource & memory management compared to simpler 8bit games and all that takes more code.

I wonder if you could poke the two bytes to jump off to a function that ignores the print but repairs the sysvars for when the program runs. Probably overkill

ParadigmShifter wrote: ↑Mon Feb 12, 2024 6:40 pm
Hmm its replacing the low byte of a function pointer with 111... maybe that just points to a RET instruction in the ROM afterwards or something

Just looking at the Rom disassembly, it's doing just that. Points to a Ret rather than the PRINT_OUT function.

10 CLEAR 24575: LOAD ""SCREEN$: POKE 23739,111: LOAD ""CODE: RANDOMIZE USR 24576

I searched for this recently and it took ages to find. I haven't tried it though, just pasted the code at the bottom of my source for when I need it.

Is the competition still open? I forgot to send in my entry.

I'm using VSCode+Dezog too. The tutorials on the Dezog github page got me started.