[VG5000] starting something via Boriel’s ZX-Basic Compiler
Modérateurs : Papy.G, fneck, Carl
- nitrofurano
- Messages : 95
- Inscription : 26 juil. 2013 15:30
- Localisation : Porto
- Contact :
[VG5000] starting something via Boriel’s ZX-Basic Compiler
finally i have something working:
http://www.boriel.com/wiki/en/index.php ... first_test
but as you can all see and verify, it is still far away of what i really wanted to do, specially when compared with what i made to other hardware: http://www.boriel.com/wiki/en/index.php ... R_HARDWARE - so the problem is not about using a cross-compiler designed for ZX-Spectrum, it is actually about that i still struggle to figure out VG5000 hardware works (specially the display processor), even by following documentation like Clefs Pour VG5000
after saying this, i’d ask:
- what might i doing wrong in that example above? why it doesn’t behave as expected? (sometimes the example even reboots or freezes on Mess/Mame emulator, very probably would happen on real hardware as well)
- since (i guess) "pure" assembly examples are very useful for this development stage, where from can we find ready stuff to be tried out? (specially if easily compilable on Pasmo, it is really a very neat cross-compiler) (and if someone made something on z88dk, be welcome sharing, even that i’m not that comfortable in C language)
and perhaps more people here, like me, would realize how amazing Boriel’s ZX-Basic Compiler is, and perhaps i guess it worth spreading (even by humbly sharing that “partially-working” example above! )
thanks in advance!
http://www.boriel.com/wiki/en/index.php ... first_test
but as you can all see and verify, it is still far away of what i really wanted to do, specially when compared with what i made to other hardware: http://www.boriel.com/wiki/en/index.php ... R_HARDWARE - so the problem is not about using a cross-compiler designed for ZX-Spectrum, it is actually about that i still struggle to figure out VG5000 hardware works (specially the display processor), even by following documentation like Clefs Pour VG5000
after saying this, i’d ask:
- what might i doing wrong in that example above? why it doesn’t behave as expected? (sometimes the example even reboots or freezes on Mess/Mame emulator, very probably would happen on real hardware as well)
- since (i guess) "pure" assembly examples are very useful for this development stage, where from can we find ready stuff to be tried out? (specially if easily compilable on Pasmo, it is really a very neat cross-compiler) (and if someone made something on z88dk, be welcome sharing, even that i’m not that comfortable in C language)
and perhaps more people here, like me, would realize how amazing Boriel’s ZX-Basic Compiler is, and perhaps i guess it worth spreading (even by humbly sharing that “partially-working” example above! )
thanks in advance!
- Mokona
- Messages : 1104
- Inscription : 17 déc. 2016 22:01
- Localisation : Nord Est des Yvelines
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
Hello,
how do you address the screen? There are two main ways of accessing it on VG5000 : either you write into RAM, either you discuss with the video processor yourself.
The first way is the simplest. The BASIC system has a routine to copy the specific RAM layout to the video processor. That makes it a fixed format and not using the EF9345 to full extent, but at least it's simple (it's plugged on the NMI and triggered each time a specific counter reaches zero or when redisplay is forced, 0x47FA to 0x47FC)
So as you might have seen in the book, screen starts at 0x4000. The layout is 80 byte for each of the 25 lines. Two bytes represent one displayable unit (let's say a character).
First of the pair is : bit 7, normal or extended mode, bits 6-0, character number
Second of the pair is : bit 7, 0 = Text mode, 1 = Graphic Mode
In Text Mode : bits 7-5 are the attributes (reverse, double width, double length), and bits 4-0 is text color.
In Graphic Mode : bits 7-5 is the background color, bits 4-0 is the foreground color
Bit 5 is Blink for both modes.
how do you address the screen? There are two main ways of accessing it on VG5000 : either you write into RAM, either you discuss with the video processor yourself.
The first way is the simplest. The BASIC system has a routine to copy the specific RAM layout to the video processor. That makes it a fixed format and not using the EF9345 to full extent, but at least it's simple (it's plugged on the NMI and triggered each time a specific counter reaches zero or when redisplay is forced, 0x47FA to 0x47FC)
So as you might have seen in the book, screen starts at 0x4000. The layout is 80 byte for each of the 25 lines. Two bytes represent one displayable unit (let's say a character).
First of the pair is : bit 7, normal or extended mode, bits 6-0, character number
Second of the pair is : bit 7, 0 = Text mode, 1 = Graphic Mode
In Text Mode : bits 7-5 are the attributes (reverse, double width, double length), and bits 4-0 is text color.
In Graphic Mode : bits 7-5 is the background color, bits 4-0 is the foreground color
Bit 5 is Blink for both modes.
- Mokona
- Messages : 1104
- Inscription : 17 déc. 2016 22:01
- Localisation : Nord Est des Yvelines
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
In a more detailed and more structured way, I've just typed a small article on it: http://www.triceraprog.fr/vg5000u-video ... ayout.html
- nitrofurano
- Messages : 95
- Inscription : 26 juil. 2013 15:30
- Localisation : Porto
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
i think i used the "second" method there (i think i was unsuccessful in the "first" method as well)
from the code you might see from the link i posted above, you might find a custom command i created:
vg5000putcharbios(x,y,chr,attr)
which is:
sub vg5000putcharbios(txpos as ubyte,typos as ubyte,tch as ubyte,tattr as ubyte):
asm
ld l,(ix+5)
ld h,(ix+7)
ld d,(ix+9)
ld e,(ix+11)
call $0092
end asm
end sub
from the code you might see from the link i posted above, you might find a custom command i created:
vg5000putcharbios(x,y,chr,attr)
which is:
sub vg5000putcharbios(txpos as ubyte,typos as ubyte,tch as ubyte,tattr as ubyte):
asm
ld l,(ix+5)
ld h,(ix+7)
ld d,(ix+9)
ld e,(ix+11)
call $0092
end asm
end sub
- nitrofurano
- Messages : 95
- Inscription : 26 juil. 2013 15:30
- Localisation : Porto
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
i don’t know if ix/iy registers create some kind of interference, like does on zx81 - Boriel’s ZX-Basic Compiler uses ix/iy registers quite intensively
- nitrofurano
- Messages : 95
- Inscription : 26 juil. 2013 15:30
- Localisation : Porto
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
i think that this one uses the "first" method, as i think you explained above - but i’m also not satisfied with the result from this one as well... :S
- Pièces jointes
-
- example01f1.zip
- (9.06 Kio) Téléchargé 207 fois
- Mokona
- Messages : 1104
- Inscription : 17 déc. 2016 22:01
- Localisation : Nord Est des Yvelines
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
Oh, I missed the code in the first place. So, vg5000putcharbios is using a third way. It's using the BIOS/BASIC System routine at 0092.
It can work. This routine is using the different variables of current status to output the right displayable unit to the current cursor place.
But your main problem I guess is that you are using IX in your code. IX is complicated to use safely, as it's used as the base adress register for EF9345 register copy in RAM. As stated in my little article : don't touch IX if you want to use BIOS/BASIC.
Because I used a SDCC for various tests and SDCC uses IX too, I stumbled on the same problems. The monitor is refreshing the screen using IX, but with rather random values of IX, as you're using it.
The first way to fix that is not to use IX, obviously. But depending on your code base size, it might be complicated.
A second way is to have your program entirely under DI. The only interrupt on VG5000 is for screen refresh (at least if no one used the IRQ vector as a user), so it's safe. Ugly but safe. Then when you want to refresh, you can do something like this :
I used that with some success. With this method, you control the refresh using the BIOS routines.
I also tried another way: use the IRQ vector to call a routine that saves my IX and puts back the BASIC value, then temper with the stack to provoke a callback to another routine at the end of the exception to put back my context.
This... sort of worked... but not completely well.
It can work. This routine is using the different variables of current status to output the right displayable unit to the current cursor place.
But your main problem I guess is that you are using IX in your code. IX is complicated to use safely, as it's used as the base adress register for EF9345 register copy in RAM. As stated in my little article : don't touch IX if you want to use BIOS/BASIC.
Because I used a SDCC for various tests and SDCC uses IX too, I stumbled on the same problems. The monitor is refreshing the screen using IX, but with rather random values of IX, as you're using it.
The first way to fix that is not to use IX, obviously. But depending on your code base size, it might be complicated.
A second way is to have your program entirely under DI. The only interrupt on VG5000 is for screen refresh (at least if no one used the IRQ vector as a user), so it's safe. Ugly but safe. Then when you want to refresh, you can do something like this :
Code : Tout sélectionner
push ix
push iy
ld ix, #0x47fa
ld iy, #0x0
ld 1(ix),#0x1 // Forces refresh. Don't touch counter
ei
halt // The IRQ will wake up the CPU
di
pop iy
pop ix
I also tried another way: use the IRQ vector to call a routine that saves my IX and puts back the BASIC value, then temper with the stack to provoke a callback to another routine at the end of the exception to put back my context.
This... sort of worked... but not completely well.
- Mokona
- Messages : 1104
- Inscription : 17 déc. 2016 22:01
- Localisation : Nord Est des Yvelines
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
On the second zip, indeed _vg5000putcharpoke uses the RAM access method. But as the other one, IX is used. That's the root of the problem. Your program is being interrupted by the screen refresh which expects IX to be 0x47fa.
That's why you have randomness and sometimes reboot. Writing to (IX+n) writes to... well it depends, but not where it's expected. Both by the BIOS and your program when returning from the interrupt, as the IRQ doesn't save IX during it's execution.
That's why you have randomness and sometimes reboot. Writing to (IX+n) writes to... well it depends, but not where it's expected. Both by the BIOS and your program when returning from the interrupt, as the IRQ doesn't save IX during it's execution.
- nitrofurano
- Messages : 95
- Inscription : 26 juil. 2013 15:30
- Localisation : Porto
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
thanks - on a zx-81 example (the slideshow, i guess) i used system variables and fastcall functions instead of those default functions based on ix - http://www.boriel.com/wiki/en/index.php ... ams_-_ZX81 - it might work - i’ll try it tomorrow morning!
- nitrofurano
- Messages : 95
- Inscription : 26 juil. 2013 15:30
- Localisation : Porto
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
for some reason it’s not working... (i wonder why, and i’ll keep trying...)
- Pièces jointes
-
- example01f8a_fastcallandsystemvariables_notworking.zip
- (49.6 Kio) Téléchargé 199 fois
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
When you send an asm code, please keep it minimal to be assembled by any assembler.
Your code uses PASMO specificities. Please remove them.
It uses also undocumented opcodes: sll. Please remove it and replace it by its hexa value (you can document the hexa code )
Keep the name variables less than 8 characters.
Since I could not assembly your code, I just had a glance.
The routine 0092H modifies the registers Af, BC, DE, HL. Push them before calling and then pop them.
What the purpose of saving IY? It is modified by the Basic ROM anyway.
What the purpose of exchanging the register to save HL. You must save the current HL.
Have a good day
Your code uses PASMO specificities. Please remove them.
It uses also undocumented opcodes: sll. Please remove it and replace it by its hexa value (you can document the hexa code )
Keep the name variables less than 8 characters.
Since I could not assembly your code, I just had a glance.
The routine 0092H modifies the registers Af, BC, DE, HL. Push them before calling and then pop them.
What the purpose of saving IY? It is modified by the Basic ROM anyway.
What the purpose of exchanging the register to save HL. You must save the current HL.
Have a good day
- Mokona
- Messages : 1104
- Inscription : 17 déc. 2016 22:01
- Localisation : Nord Est des Yvelines
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
With randomness and some loops, the code is complicated to follow for debugging the basic output of a character. There are a lot of static variables in the way.
You could start with outputing a simple string first.
As joaopa said, be careful of the registers touched by the PUTCHAR routine. In your case, as every data seems to be stored and fetched from memory for each usage, it doesn't seem to be the cause of the problem.
You could start with outputing a simple string first.
As joaopa said, be careful of the registers touched by the PUTCHAR routine. In your case, as every data seems to be stored and fetched from memory for each usage, it doesn't seem to be the cause of the problem.
- nitrofurano
- Messages : 95
- Inscription : 26 juil. 2013 15:30
- Localisation : Porto
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
thanks for all the feedback, you all shared important tips about simplifying the whole process (as i want to start a simple example only using Pasmo alone - anyway, sorry that Boriel’s ZX-Basic Compiler creates lots of “garbage” in the code, surprisingly its results often works on a quite range of hardware)
(the variable names i use are usually short, mostly because i reuse them all the time - the routine names are long because i have a really crappy memory (the same way i enjoy having the code compact enough for avoid scrolling, for example), i think i’m really getting old! )
anyway, in the meanwhile, i advanced on an example that seems to work now - my concern is that how inaccurate seems the line position used from $0092 routine, is that exactly like that?
(the variable names i use are usually short, mostly because i reuse them all the time - the routine names are long because i have a really crappy memory (the same way i enjoy having the code compact enough for avoid scrolling, for example), i think i’m really getting old! )
anyway, in the meanwhile, i advanced on an example that seems to work now - my concern is that how inaccurate seems the line position used from $0092 routine, is that exactly like that?
- Pièces jointes
-
- example01f8c_fastcallandsystemvariables.zip
- (47.21 Kio) Téléchargé 202 fois
- Mokona
- Messages : 1104
- Inscription : 17 déc. 2016 22:01
- Localisation : Nord Est des Yvelines
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
Ah yes, I see something that looks like the code in the .bas file now.
What do you mean by inacurrate ?
(I see you're back using IX, doesn't it cause problems? I don't see it protected much)
What do you mean by inacurrate ?
(I see you're back using IX, doesn't it cause problems? I don't see it protected much)
- nitrofurano
- Messages : 95
- Inscription : 26 juil. 2013 15:30
- Localisation : Porto
- Contact :
Re: [VG5000] starting something via Boriel’s ZX-Basic Compiler
finally i’m starting to get some stuff working! thanks! \o/
(i wonder if ix usage still exists, i’m now trying to avoid it all i can)
the inaccuracy issue is because it looks having a bit of offset - i had to place in the line 6 for appearing in the line 0, 7 seems skipped, 8 for the line 1, 9 for the line 2, 10 for the line 3, and so on... - i expected to place in the line 0 for appearing in the line 0, 1 on 1, 2 on 2 and so on...
(i wonder if ix usage still exists, i’m now trying to avoid it all i can)
the inaccuracy issue is because it looks having a bit of offset - i had to place in the line 6 for appearing in the line 0, 7 seems skipped, 8 for the line 1, 9 for the line 2, 10 for the line 3, and so on... - i expected to place in the line 0 for appearing in the line 0, 1 on 1, 2 on 2 and so on...
- Pièces jointes
-
- example01f9c1_improving.zip
- (50.73 Kio) Téléchargé 190 fois