- This topic has 522 replies, 8 voices, and was last updated 4 years, 8 months ago by
.
-
Posts
-
… I will play as often as I can over the weekend. And I will continue my own experiments / investigations of port b input-output behavior. There are some things I still do not understand. Could you shortly describe the “fix” you implemented to make version 45 faulty-tolerant?
“easy”:-)
More or less what was hinted in the blog article…1) Remove ALL “INC/DEC”
in regards to VIA_PORT_B (I don’t use NEG/COM with VIA, who would???)2) This also means do not use ANY of those BIOS functions:
;Wait_Recal EQU $F192 ;
;Joy_Analog EQU $F1F5 ;
;Joy_Digital EQU $F1F8 ;
;Recalibrate EQU $F2E6 ;
;Moveto_x_7F EQU $F2F2 ;
;Moveto_d_7F EQU $F2FC ;
;Moveto_ix_FF EQU $F308 ;
;Moveto_ix_7F EQU $F30C ;
;Moveto_ix_b EQU $F30E ;
;Moveto_ix EQU $F310 ;
;Moveto_d EQU $F312 ;
;Print_Str_hwyx EQU $F373 ;
;Print_Str_yx EQU $F378 ;
;Print_Str_d EQU $F37A ;
;Print_List_hw EQU $F385 ;
;Print_List EQU $F38A ;
;Print_List_chk EQU $F38C ;
;Print_Ships_x EQU $F391 ;
;Print_Ships EQU $F393 ;
;Mov_Draw_VLc_a EQU $F3AD ;count y x y x …
;Mov_Draw_VL_b EQU $F3B1 ;y x y x …
;Mov_Draw_VLcs EQU $F3B5 ;count scale y x y x …
;Mov_Draw_VL_ab EQU $F3B7 ;y x y x …
;Mov_Draw_VL_a EQU $F3B9 ;y x y x …
;Mov_Draw_VL EQU $F3BC ;y x y x …
;Mov_Draw_VL_d EQU $F3BE ;y x y x …
;Draw_VLc EQU $F3CE ;count y x y x …
;Draw_VL_b EQU $F3D2 ;y x y x …
;Draw_VLcs EQU $F3D6 ;count scale y x y x …
;Draw_VL_ab EQU $F3D8 ;y x y x …
;Draw_VL_a EQU $F3DA ;y x y x …
;Draw_VL EQU $F3DD ;y x y x …
;Draw_Line_d EQU $F3DF ;y x y x …
;Draw_VLp_FF EQU $F404 ;pattern y x pattern y x … $01
;Draw_VLp_7F EQU $F408 ;pattern y x pattern y x … $01
;Draw_VLp_scale EQU $F40C ;scale pattern y x pattern y x … $01
;Draw_VLp_b EQU $F40E ;pattern y x pattern y x … $01
;Draw_VLp EQU $F410 ;pattern y x pattern y x … $01
;Draw_Pat_VL_a EQU $F434 ;y x y x …
;Draw_Pat_VL EQU $F437 ;y x y x …
;Draw_Pat_VL_d EQU $F439 ;y x y x …
;Draw_VL_mode EQU $F46E ;mode y x mode y x … $01
;Print_Str EQU $F495 ;(didn’t look at more exotic functions)
3) Tweak the game till it runs again, and looks good
Chris
PS
As you would expect of me – Vide now also features a “faulty” switch… 🙂I had to get up early today and hide some Easter eggs, real ones – not code, in the garden for the kids. Now Iam sitting here with a first cup of coffee, waiting for them to wake up, and I cannot stop thinking about VB.
So, next try. What would happen, if PB7 at some point, in whatever strange context, unintentionally changes its value? I know it is just the ramp signal, but could that lead to a crash?
… I will write again later. They have woken up 🙂
Happy Easter to you all!
I played the last beta version yesterday night (400 levels).
My first feedback : nice job and no crash for me! 😊; the action is “sharp” and the pleasure to play is there!
3 little details: now in the “easy mode” it seems we can get the “extra life” bonus. Normal?
In my opinion, using the “4 shots” against the first boss seems more difficult than before (and more than the “3 shots” paradoxically)
It would be nice to disable the button 3 when we shot the ennemies (button 4): pushing the 2 buttons at the same time modifies the display. It is not really a problem because there is no reason to push them at the same time, but it would be “cleaner”.
@Chris, @Peer and all: Happy Easter and thank you for your brilliant ideas and hard work on Vectorblade!
Thx for playing!
Since you play from the VecFever, and I didn’t change the savegame – name, you still have the “old” settings stored.
That also means the “life” achievement is still active :-).4 shots – have always been more difficult with the first boss – it’s because they are so “wide spread” – they tend to hit more insects….
Happy easter!
Chris
PS
Perhaps interesting for you:
Has a short passage about Vectorblade :-).
Nope.. Ramp wouldn’t cause a crash…
One other thing that I can think of… (VIA related)…
If for whatever reason, interrupt flags are not set – that would cause endless loops – where I wait for them.That did happen in the past… can’t remember what caused that.
It had something todo with timer T2 (the wait recal timer).
It was a programming error – not a VIA bug. Like clearing the flag and than waiting for it without starting the timer again… or something similar.Although the timer keeps runing (and reaches 0) – no “second” interrupt will be issued after the first “0” reach. So waiting for the flag to change will never happen.
Darn – I didn’t write that one down.
Cheers & happy easter to you too!
Chris
Nope.. Ramp wouldn’t cause a crash…
Oh, come on, I am running out of pins. Please, give me a crash! 😉
Here is why I asked this:
I did some experiments on a real console. I left VIA_DDR_b as it is configured by Init_VIA(). So, PB7 and PB4-0 are in output mode, and PB6+5 are in input mode. I then did write/reads to VIA_port_b. Reading PB4-0 gives me the last pattern I stored. Fine. PB6+5 I ignored. But no matter which 8-bit value I put in VIA_port_b, when I read PB7, it always yielded a one. The asm code is:
ldb _n stb *_dp_VIA_port_b ldb *_dp_VIA_port_b stb _mSo there is nothing inbetween the write and the read. Now, suppose that I use the following code:
ldb #0 stb *_dp_VIA_port_b inc *_dp_VIA_port_bMy theory is that the same thing should happen, i.e. the inc reads a one in PB7 and then actively writes a #129 to VIA_port_b, and thus sets ramp to high.
I cannot verify this, because reading VIA_port_b after the inc instruction would be also prone to always reading a one in PB7.
But I was “hoping” that there might be some exotic context in which inaccidently setting ramp to one in this way (by using inc) could cause a crash, or possibly an endless loop, or some disruption of the timers, or … ?
Please, give me a crash! 🙂
PB7 is in its default state “overwritten” by Timer T1.
If timer is running PB7 is 0 (ramping ON), if timer reaches 0, PB7 reads 1 (ramping off).
As said, you can change that behavior with the CNTL register of VIA
So in other words, writing PB7 (when it is in its default state and when it is in output mode) does not have any effect at all?
And just for the sake of completeness, can you give me a code example where you used the DEC just like you used the INC in the VIA post?
So in other words, writing PB7 (when it is in its default state and when it is in output mode) does not have any effect at all?
I actually don’t know if PB7 is latched.
If it is latched – VIA would remember what was last written and when switched with CNTL THAN the value would be available.
But otherwise – no, I don’t think it has any effect.And just for the sake of completeness, can you give me a code example where you used the DEC just like you used the INC in the VIA post?
Hm, just replace the inc with dec :-).
No – really!
Usually you do a inc/dec (with VIA port b) to switch off (sometimes on – than you certainly have to chose between inc/dec) the MUX.
Since the MUX enable bit is PB0, … in resepct to switching off (changing bit 0 to 1)
dec and inc do exactly the same :-).Chris
That is what is what I still find confusing. INC and DEC would both have the same effect on PB0, but what about the other pins? If the read-cycle e.g. fetches an 8-bit zero, then the write-cycle of INC would put a 0 to PB6, while DEC would put a 1 to PB6. Am I missing something here?
You only use DEC when PB is >0.
I have never seen it used when PB is 0 – you are right – that would provoke really interesting effects 🙂
I actually don’t know if PB7 is latched.
If it is latched – VIA would remember what was last written and when switched with CNTL THAN the value would be available.
But otherwise – no, I don’t think it has any effect.Actually…
I am pretty sure PB7 is latched – if I remember right – exactly this phenomenon happened to me while changing “to be faulty resistant”.
My printStr was one line off – that was, because the PB7 contained a zero (from a CLR) and when switching with CNTL – the beam automatically started moving vertically…
Took some time to find that rascal – wonder why I didn’t remember that some hours ago…
- The forum ‘Vectorblade beta test’ is closed to new topics and replies.