While i was bored...

Discussion about ZX80 / ZX81 Software
User avatar
Andy Rea
Posts: 1606
Joined: Fri May 09, 2008 2:48 pm
Location: Planet Earth
Contact:

While i was bored...

Post by Andy Rea »

Wrote a little something

it places CALL nnnn instructions into D_FILE so cannot work on all systems, works well in eightyone althought my pc is a bit rubbish and it goes jerky sometimes, but it has been tested on real zeddy and works fine

Bye for now Andy
MAD.P
go on you know you want to...
(5.42 KiB) Downloaded 207 times
what's that Smell.... smells like fresh flux and solder fumes...
User avatar
siggi
Posts: 988
Joined: Thu May 08, 2008 9:30 am
Location: Wetterau, Germany
Contact:

Re: While i was bored...

Post by siggi »

GREAT!

Hope that you are more often "bored" ;)

Siggi
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Re: While i was bored...

Post by sirmorris »

:D Huzzah! :D

Nice work Andy!

Does this need m1not to run on real hardware?
Last edited by sirmorris on Tue May 24, 2011 11:01 pm, edited 1 time in total.
User avatar
Andy Rea
Posts: 1606
Joined: Fri May 09, 2008 2:48 pm
Location: Planet Earth
Contact:

Re: While i was bored...

Post by Andy Rea »

well this is to do with the M1 decoding for the 48-64K range i believe, it will run on zxpand with a small modification mentioned in the other thread. it also works loaded from tape on my pretty much standard 16K zeddy (i say standard as it is internal 16K, but nothing else moddified).

does not need HRG enabled as it never changes the I reg. it just plays about with the D_file, by inserting 2 different CALL nnnn as siggi pointed out somewhere else if you have M1 decoding in the 48-64K then the $CD (call) is read and executed but it's operand the following 2 bytes don't make it as some other memory gets accesses instead, NO M1 signal on plain memory reads.

hope that helps
Andy
what's that Smell.... smells like fresh flux and solder fumes...
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Re: While i was bored...

Post by sirmorris »

I thought I needed to factor M1 into the equations ... :?

What would happen if it wasn't used? Would that be a good thing??

C
User avatar
Andy Rea
Posts: 1606
Joined: Fri May 09, 2008 2:48 pm
Location: Planet Earth
Contact:

Re: While i was bored...

Post by Andy Rea »

as far as i can see you only need to factor M1 if the zeddy has other memory mapped to the 48-64k region, such as battery backed storage or paged ram ect, of course that ram can only be used for storage as the normal video needs to use that memory space also. as i wrote elsewhere by removing M1 fronm the equation it allows ZXtricator to run (which i believe uses the same trick to hook into the display routine), and i suspect that few ZXpand users will have other memory installed [1], i guess a possibble solution to all cases would be to leave the gal as is and fit a small SPDT switch so you can switch that input between GND (effectivly removing M1 from the equation) or the real M1 for users with memory mapped to 48-64K.

as yet i have not encountered any unwanted side effects from my little mod.

Regards Andy


[1] this is pure speculation.
what's that Smell.... smells like fresh flux and solder fumes...
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Re: While i was bored...

Post by sirmorris »

Cheers mate, I'll update the GAL and run a test suite.

ZX-defender, zxtricator, your demo - anything else which shows up the problem?
RWAP
Posts: 1348
Joined: Thu May 08, 2008 8:42 am
Location: Stoke-on-Trent, UK
Contact:

Re: While i was bored...

Post by RWAP »

Andy Rea wrote:Wrote a little something

it places CALL nnnn instructions into D_FILE so cannot work on all systems, works well in eightyone althought my pc is a bit rubbish and it goes jerky sometimes, but it has been tested on real zeddy and works fine

Bye for now Andy
MAD.P
OK - now this reflects my lack of knowledge on the ZX81, so sorry if it sounds dumb, but what does this actually achieve?

Does it allow a program to load and run without having to enter the RUN command?
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Re: While i was bored...

Post by sirmorris »

It's nothing to do with that Rich - auto-program execution is to do with how the 'nxt-line' system variable is set when the program is saved. In direct mode it's not pointing to any line of code in the program but during execution it's updated to point to the next line of basic to execute. That's why a program which contains a SAVE command will continue at the line after the SAVE when you reload it.

Andy's program is doing some clever display file manipulation - if you remember the display file is 'executed' by the processor during display generation. I'm very much looking forward to hearing how it works... Andy?

(C:
User avatar
Andy Rea
Posts: 1606
Joined: Fri May 09, 2008 2:48 pm
Location: Planet Earth
Contact:

Re: While i was bored...

Post by Andy Rea »

Hmmm it's not pretty....
mad3.asm
(28.29 KiB) Downloaded 182 times
it started off with an experiment to see if i could manipulate the position of characters mid line by inserting executable code, so for example instead of a space you could put a RET Z which would fail to return during D_file execution and use up 5 cycles so the next character would be displayed displaced by 10 pixels from the previous one instead of 8 (remeber 1 z80 cycle is 2 pixels) so after some careful studing of the available opcodes with bit 6 set (required so they are executed instead of generate a character i found some that used 5 cycles RET Z, 7 cycles LD A,(HL) , now by using combinations of 5 and 7 and 4 (normal space character) cycles you can get delays of 5+4 = 9 , 5+5 = 10 , 7+4 = 11, and no delay or 12 (7+5) which i actually use but either was it doesn't really matter 12 goes into 4 so the end result is the same it would just need paddign with spaces. anyway

so every 3 frame that shifts either way by 2 pixels, the d_file is hacked by placing a call to a special video routine that spends most of the first 4 scanlines doing nothing ! then at the right moment displays 4 scanlines to diplay the top bar, then it displays 8 scanlines with the special bytes, and finally display 4 more scanlines to diaplay the bottom bar, the top and bottom lines are stored once each and displayed 'excuted' 4 times each, i do not mess arounf with vsync to reset the character line scounter. the middles line has 4 varients stored and depending on where exactly the ZX81 is to be displayed depends on which varient gets displayed.

the logo starts off with each byte set to 1 then it loops round xor-ing (with a byte from rom) and then adding 1 until all the bytes are at the desired value, of course you have to mask out bit 6 ! but i also mask out bit 5. when the logo is complete (by comparing it to a copy of the completed thing ! ) it is shifted to the left by 1/2 char (1 quadrant) i suppose i could just have stored a shifted copy also... but it proved that trying to do a scroller that shifted by 1/2 char every frame was going to be really hard...until...

frame flipping, so i have 2 buffers...no 1 complete 24 lines fake d-file and 1 partial fake d_file, the second of which has the shifted logo in it, so now i can scroll alternate frames by 1 whole char (easy peasy) only 6 lines to scroll, and update 1 coloumn of chars. the character set is strongly based on the sinclair logo (like you couldn't tell )

each time the d_file is excuted we get 3 character lines doing the ZX81 fx, then 6 lines that alternate each frame, and then 1 blank line (mostly of which is spent waiting) and finnally 14 lines always from fake_d_file_1.

the scroll text contains 2 special bytes $ff and $fe, it is also stored in ASSCI :? so i have to test for a space but the letters are i just subtract the appropriate number. $ff signifies the end of the text and resets the pointer back to the begging, and the $fe triggers the blobs / balls.

the blobs... yeah right was a bit of a pain... there are 12 blobs each has an x and y array that itself holds an index value to an offset array, the y offset array contains multiples of 33, and the x offset array values between 1 and 31 ( 1 because i don't increment the d_file value by 1 initially), each blog starts with it's x.y values at 0 and increments after the blob is earsed, x resets at 89, y reset at 48, each new blob is introduced 7 frames after the previous one ( i think it might be 8) until the maximum number of blobs is reached, each blob is earsed, moved and redrawn every frame...

thats about it, i haven't really tried to optimise the code much, and some comments don't make sense because i altrred bits of code without changing the comment....

regards Andy
what's that Smell.... smells like fresh flux and solder fumes...
Post Reply