Programming the 1540 / 2031 Floppy

[MrSterlingBS]

Hello,

At the moment I'm trying to get some small programs to run on the 1540 floppy disk or, better yet, the IEEE 2031 LP. I was able to run two programs successfully. One is an addition and the second is a multiplication. Both programs can be tried out in BASIC. The values ​​to be added or multiplied are stored in line two and three. 7+9 or 7*9
The result can be taken from the memory dump.

Now my actual concern. Does anyone here in the forum have experience with implementing the program in assembler?
I would be very grateful for help.

Best regards, Sven

Code: Select all

0 printchr$(147)
1 open1,8,15
2 print#1,"m-w"chr$(15)chr$(3)chr$(1)chr$(7)
3 print#1,"m-w"chr$(16)chr$(3)chr$(1)chr$(9)
7 fori=0to12
8 read a
9 print#1,"m-w"chr$(i)chr$(3)chr$(1)chr$(a)
10 next
15 print#1,"m-e"chr$(0)chr$(3)
20 forx=15to17
25 print#1,"m-r"chr$(x)chr$(3)chr$(1)
30 get#1,a$
40 printasc(a$+chr$(0));
50 next
60 close1
65 end
70 data 120,24,173,15,3,109,16,3,141,17,3,88,96

Code: Select all

0 printchr$(147)
1 open1,8,15
2 print#1,"m-w"chr$(81)chr$(5)chr$(1)chr$(7)
3 print#1,"m-w"chr$(80)chr$(5)chr$(1)chr$(9)
7 fori=0to38
8 read a
9 print#1,"m-w"chr$(i)chr$(5)chr$(1)chr$(a)
10 next
15 print#1,"m-e"chr$(0)chr$(5)
20 forx=80to81
25 print#1,"m-r"chr$(x)chr$(5)chr$(1)
30 get#1,a$
40 printasc(a$+chr$(0));
50 next
60 close1
65 end
70 data 120,173,81,5,74,141,81,5,169,0,162
72 data 4,144,4,24,109,80,5,106,110,81,5,144
76 data 4,24,109,80,5,106,110,81,5,202,208
78 data 233,141,82,5,96

[MrSterlingBS]

Hi,

I had forgotten the great website Codebase64. There is enough source code there to try out.
I hope to be able to do multiplication and division for 3D calculations this way. This should happen in parallel while the screen is being deleted and the data is being loaded from the buffer into the screen. Here we have about 30-50 thousand cycles to do this. Depends on the size of the screen.

If there is someone out there who has already realized this I would be very happy about the routine.

BR
Sven

[tlr]

I had forgotten the great website Codebase64. There is enough source code there to try out.
I hope to be able to do multiplication and division for 3D calculations this way. This should happen in parallel while the screen is being deleted and the data is being loaded from the buffer into the screen. Here we have about 30-50 thousand cycles to do this. Depends on the size of the screen.

I guess more like 22k cycles if you want full frame rate?
Anyway, the tricky part here is that the IEC routines in the kernal are very slow so you’ll have to roll your own custom transfer code. If you also need to support IEEE, that has to be a separate implementation.

Custom transfer + drive side calculations have been done many times with the c64 + 1541, but I haven’t seen that for the vic20. The principle is the same however.

[MrSterlingBS]

Hi, thanks for the tips. Do you have a fast IEC transfer routine to share?

Bacause of the clear and copy time, i use a 144x224 pixel screen. There i like to clear the screen size 144x160. This needs a little bit more than 14.400 cycles, in addition, there is the copy routine of the rendered image from the memory to the screen. 30.000 cycles both together 45.000 cycles.

BR
Sven

[tlr]

Hi, thanks for the tips. Do you have a fast IEC transfer routine to share?

Not a ready made one for the vic20, no.

Bacause of the clear and copy time, i use a 144x224 pixel screen. There i like to clear the screen size 144x160. This needs a little bit more than 14.400 cycles, in addition, there is the copy routine of the rendered image from the memory to the screen. 30.000 cycles both together 45.000 cycles.

Why do you need to copy?

[srowe]

Hi, thanks for the tips. Do you have a fast IEC transfer routine to share?

Here

[Mike]

Why do you need to copy?

The (vector) graphics is supposed to be pre-rendered into a shadow bitmap and then blitted over to the display bitmap to reduce flicker.

There is not enough RAM accessible for the VIC to hold two bitmaps of the given size, hence the need for a memory copy instead of "just" changing the equivalent of a display bitmap base register.

[tlr]

Why do you need to copy?

The (vector) graphics is supposed to be pre-rendered into a shadow bitmap and then blitted over to the display bitmap to reduce flicker.

There is not enough RAM accessible for the VIC to hold two bitmaps of the given size, hence the need for a memory copy instead of "just" changing the equivalent of a display bitmap base register.

Fair enough. If that size is required, then copy it is. It’s very expensive though.

You could perhaps consider a smaller number of chars used for the bitmap by arranging the chars in a circular fashion?
Rotating vector objects tend to fill a circular area.

[Mike]

You could perhaps consider a smaller number of chars used for the bitmap by arranging the chars in a circular fashion? Rotating vector objects tend to fill a circular area.

I suppose the use case is a cockpit view of a space ship, where there is not a single (rotated) vector object, but multiple, and they are not fixed in the center.

[MrSterlingBS]

Hi, thanks for the tips. Do you have a fast IEC transfer routine to share?

Here

THX

[MrSterlingBS]

I wrote a small program that can measure the speed. I hope it is calculated correctly.
17 blocks of 256 bytes each are loaded. That is 4352 bytes. The factor is then 4352bytes*60/1024bytes/kb=255
The factor is divided by the jiffies.

First, MG must be loaded and then an example image from the diskette which is entered into the code as a string.

Code: Select all

1 @on:@clr
2 n$="google"
3 ti$="000000":@loadn$,8:t=ti:z=255/t
5 @return:printz"kb/s"

the program does not seem to produce the correct results with jiffy VIC / jiffy DOS 1541?

[tlr]

I wrote a small program that can measure the speed. I hope it is calculated correctly.

Interrupts are periodically disabled during IEC access. Jiffies won’t be accurate. You’ll have to manually use a timer.

I don’t think you will get any gain doing single multiplications, but matrix rotation could be worth it assuming optimized transfer.

[MrSterlingBS]

What a bummer, I thought it would be so easy.

[Mike]

In CBM DOS, only 254 bytes of a block are used for data. The first two bytes of each block either contain the sector link or the 'last block' tag together with the number of valid bytes in that sector.

What actually gets transmitted to the computer are the load address and the actual file data, 4097 bytes in total for a MG picture file (see the manual, Appendix D). A few bytes are also sent to the floppy (the file name, in particular) during the KERNAL load procedure, and @LOAD itself and the assignment to T (for taking the time) need also be taken into account. That overhead is minimized though when larger files are used as test objects. *)

The calculation of the transfer rate for printout is not time critical. For a better comprehensibility, this calculation should leave its method transparent, and not collapse the factors into one constant, i.e.:

t/60: file transfer time in seconds

4097/(t/60): bytes per second for whole file

(4097/1024)/(t/60): KB/s for whole file

... and lines 3 and 5 should thus be changed to:

Code: Select all

3 TI$="000000":@LOADN$,8:T=TI
5 @RETURN:PRINT(4097/1024)/(T/60)"KB/S"

... eliminating the introduction of and unnecessary assignment to the variable Z.

...

Plus what tlr wrote. Using the jiffy clock during IEC file transfers is somewhat inaccurate. However, interrupts still happen continuously every 1/60 s, and are re-enabled at least once every 1 ms (between each byte transfer), so I would not expect a grossly wrong result **).


*) not with @LOAD though. You are only supposed to load MG picture files with this command, not anything else. Use the procedures described elsewhere to load other binary files instead.

**) a change of sector or track during file transfer will take the drive more than 1 ms, possibly more than 16 ms, to send the next byte. Those interrupts might be lost for updating the jiffy clock.

[tlr]

What a bummer, I thought it would be so easy.

Optimizing vector calculations is not trivial. Asymmetric multiprocessing on an 8-bit system is not trivial either, especially since you have a bandwidth limited link.

Make sure you are optimizing the right thing! I’d start with the multiplication, then rotation, and after that consider any multiprocessing.