Read keyboard from assembly

[zx81user]

btw. shouldn't this post be in another section/subforum?

Yes, it should be moved to the Development section.

I wonder if the simply reading in a game via IN instruction doesn't result in screen flickering as the line counter should be reset by IN ($FE) and this process is not synchronized.

I've not noticed any...?

I think this should work just fine. Reading the keyboard port will reset the line counter but it doesn't matter because the processor is not busy creating the screen at that time. Anyway, I choose the Dr Beep's solution with a slight modification. I wanted to use the keyboard to set the time for my clock (using 0 - 9, and some letters for setting hours, minutes etc). However, while programming this, I realized the program was never going to fit within 1k no more so I abandoned the idea and went for a simple basic solution (INPUT A$) and read A$ within the assembly program. This solution was only like 30 bytes in total or something like that.

Michel

[dr beep]

I realized the program was never going to fit within 1k no more so I abandoned the idea

Is this proven?

I am working on a new version of SOKOB-ONE with now 20 new levels and ZXPAND support, so 5 more levels AND extra support. Quite a lot extra in just 1K.

So I think a lot can be added even after finishing a program.

[PokeMon]

I wanted to use the keyboard to set the time for my clock (using 0 - 9, and some letters for setting hours, minutes etc). However, while programming this, I realized the program was never going to fit within 1k no more so I abandoned the idea and went for a simple basic solution (INPUT A$) and read A$ within the assembly program. This solution was only like 30 bytes in total or something like that.
Michel

No I don't think that this hits 1k. It's more complex in BASIC, creating variables, line numbers, line lenght, decimals (integers) coded as both ASCII and floating point.
For reading 0-9 you just need two IN instructions for both "half-rows" 0-4 and 5-9.
I think you maybe choosed an EXPANDED display file which takes about 800 bytes in general without any code.

In the ZX-IDE you can set DFILE to either EXPANDED or COLLAPSED.
For the 1k you should always use collapsed.
I am only guessing but you can code much in 1k assembler.

[RWAP]

btw. shouldn't this post be in another section/subforum?

Yes, it should be moved to the Development section.

Agreed - moved.

[zx81user]

I wanted to use the keyboard to set the time for my clock (using 0 - 9, and some letters for setting hours, minutes etc). However, while programming this, I realized the program was never going to fit within 1k no more so I abandoned the idea and went for a simple basic solution (INPUT A$) and read A$ within the assembly program. This solution was only like 30 bytes in total or something like that.
Michel

No I don't think that this hits 1k. It's more complex in BASIC, creating variables, line numbers, line lenght, decimals (integers) coded as both ASCII and floating point.
For reading 0-9 you just need two IN instructions for both "half-rows" 0-4 and 5-9.
I think you maybe choosed an EXPANDED display file which takes about 800 bytes in general without any code.

In the ZX-IDE you can set DFILE to either EXPANDED or COLLAPSED.
For the 1k you should always use collapsed.
I am only guessing but you can code much in 1k assembler.

Sure that is true, but if I would do everything in the clock software itself, there is a lot more that needs to be done. For example, I need to press a button and set the clock into settings mode, blinking the hours, then I need to read the keyboard, convert the numbers into a BCD code, store it somewhere, advance to the next item (minutes), blink the minutes, stop the seconds, read keyboard etc etc until finally someone presses the button to "start the clock". It's not only just reading a few digits, it's all the other bits and pieces that make setting the clock that way work.

Now I just do a read a$ in BASIC which is 8 bytes; then it needs some storage for the variable (7 bytes) to read 4 numbers (HHMM), then I read this in assembly and move it to my own buffer substracting the number 28 (22 bytes), then convert it into BCD (26 bytes). Total requires 63 bytes (ok, I was a bit too optimistic with my 30 bytes though ). I could probably combine the move/substract routine and BCD conversion into 1 routine saving a few bytes. Anyway, now try to write a time set routine that can do all that in assembler in less than 63 bytes. I don't think it can be done.

Michel

[PokeMon]

We are not talking about 65 bytes.
In a 1k program you have about 750-800 bytes free for an assembly program (with small BASIC start statement like 10 REM .... and 20 RAND USR ...) with a collapsed display file which is nearly empty. In your video you only print time in the first screen line, so display file is taking something about 35 or 40 bytes only.
Take a look at the 1k games of Dr. Beep what can be done including a graphic screen.

I think my fastloader code is using about 50 or 60 bytes only transferring data in high speed.

[zx81user]

We are not talking about 65 bytes.
In a 1k program you have about 750-800 bytes free for an assembly program (with small BASIC start statement like 10 REM .... and 20 RAND USR ...) with a collapsed display file which is nearly empty. In your video you only print time in the first screen line, so display file is taking something about 35 or 40 bytes only.
Take a look at the 1k games of Dr. Beep what can be done including a graphic screen.

I think my fastloader code is using about 50 or 60 bytes only transferring data in high speed.

I'll post another thread with the source code, you can have a look yourself

Michel