leomil72 / lm80c Goto Github PK

When playing biscola.bas, occasionally the sound generator is not turned off (in the emulator you can hear an high-pitched continuous tone that you won't hear on the real machine). The issue manifests once in two or three complete briscola matches.

As the issue occurs and the game goes on, I still can hear the "card shuffle" sound, but after it the voice is never turned off (which is very odd).

I stopped the program and dumped the state of the sound chip, you can see bit 0 of reg7 is 0 instead of 1:

Does this gives you a clue?

BASIC should be able to print in screen 2 mode, allowing to change foreground and background colors on per-character basis. This way programs could me more "colorful" without the limitations imposed by screen 1.

Best would be have the BASIC prompt in screen 2 and allow full editing, in other words treating screen 2 like a text mode (perhaps this could be the only text mode supported by the firmware--the others are not very useful).

Advantages:

• more colors!
• reverse characters possible (by inverting colors)
• cursor blinking with reverse or other effect (e.g. a colorful cursor)

Disvantages:

• needs to keep a separate buffer for screen map and color map 40 x 24 x 2 (could these buffers be placed in VRAM ?)
• slow to scroll and to print to

The Amstrad CPC does it this way: it has the prompt and the editing in graphic mode and has a non-blinking reversed cursor.

it would be nice to have the MOD operator, sometimes you need it and you have to emulate it via INT().

keys from 4 to 8 do not match the actual key labels of a C16 keyboard, e.g key #4 is not F4 (SHIFT+F1) but it's 'F5' (SHIFT+F2). HELP is not key #8 but #4. Is that intentional?

I've re-checked it and I think I got it right in the emulator.

I spent the whole morning debugging why 0 PRINT TMR(0)/100:GOTO 0 was not counting seconds as it was supposed to do. I checked almost everything in the emulator -- only many hours later I realized that the act of calling TMR(0) does affects the counting itself! That's because of the DI and EI instructions used in the TMR routine. So if you call it repeatedly, counting slows down considerably. Scrolling the video also slows it to a certain extent, I guess for the same reason (VDP accesses are in DI mode).

I don't think much can be done to fix this issue, perhaps the only thing would be reducing the 100Hz frequency of the CH3 timer, in order to mitigate the chance of missed increments. With prescaler set to 256 the next good value would be 60 Hz (constant value 240).

This is an interesting project! My only concern is the keyboard module choice. While there were Commodore 16 keyboard modules sold via surplus back in the 80s and 90s, that was... back in the 80s and 90s, and the store that sold them is no longer around (RIP Radio Shack), so getting these modules is very unreliable and can get expensive on eBay. From what I've seen, it's just a matrix of switches, but it would be really nice to have the connector and the matrix documented in this repository, so that someone could develop a keyboard module with modern parts for it...

currently the only way of loading programs is via terminal emulation over serial, this means you can't load or save true binary files, or even BASIC programs in its native tokenized form.

My proposal is to have the commands SAVE and LOAD to transfer programs over the existing serial line. The protocol could be like as this:

• sync byte (repeated n times)
• 4 bytes header
• 1 byte type of file (binary at fixed address or basic relocatable)
• filename + 0x00
• (word) number of bytes
• (word) address
• actual bytes
• (word) checksum

(note: the LOAD command have to set the PROGND pointer at the end of the loading).

If slower baudrates are allowed (e.g. 2400), it would be possible to SAVE and LOAD from a cassette tape (or any other audio source) like a real home computer of the '80s 😄. (In such case the header bytes at the start are mandatory to throw away the random characters).

at the command prompt, if I type CTRL+H and then RETURN the machine does reset.

Firmware 3.7.

sometimes BASIC programs require you to input uppercase letters but the LM80C is lowercase by default. Since the SHIFT LOCK in the C16 keyboard doesn't work as a true CAPS LOCK I suggest to implement a caps lock state in the firmware.

A simple bit that is toggled by some key combination, e.g. CTRL+SHIFT or C=+SHIFT.

key 8, "aaa"

sets the key to AAA (uppercase) instead of maintaining it lowercase.

Also,

key 8, chr$(123)

produces a ?syntax error

is this a desired behavior?

the RUN STOP key doesn't stop a running BASIC program (but ESC does it).

It would be nice if you also supported SHIFT + RUN STOP for "RUN", moving it out of KEY #2.

This project is awesome! ☺️

I have a question about the access timings for the VDP. I noticed in your firmware code you put three NOPs between VDP accesses. But checking the TMS9918 manual (see below) it talks about a 8μs delay which would be 8 nops.

I derived the number from this calculation:

• Z80 clock period is 1/3.6864 ≈ 0.271 μs
• 8μs / 0.271 ≈ 30 Z80 clock cycles.
• in NOP terms, 30 / 4 ≈ 8 nops

Since your code actually works, what am I missing ? 😄 It would be nice to emulate such strict timings in order to check if a program can run on a real LM80C.

I can't find any reference on the docs about the daisy chain interrupt priority. From the schematics I deduced SIO has the highest priority, then CTC, and lastly PIO. Is that so (or it's reversed?)

10 a=inkey(0)
20 if a<>0 then print a
30 goto 10

when pressing random keys on the keyboard it seldom skips groups of keys for about 1-2 seconds and then it does resume detecting key presses.

Try for example pressing Z 20 times at about 1/2 secs intervals.

It doesn't happen if you have a longer time period e.g. INKEY(100). Assuming it's not emulator issue, my guess it that the INKEY routine is eating unprocessed characters at the end of the routine (ENDINK).

Can you reproduce this issue on the real machine?

I finally managed to write a program that uses the NMI interrupt with the new firmware. I discovered the hard way that the VDP needs to be acknowledged of the end of the interrupt by the read of the status register; otherwise it won't trigger another interrupt.

Below you'll find the program I wrote, could you please execute it on the real LM80C and send me back a picture of the screen? I need it to verify the accuracy of the emulator.

Anyway there seems to be a big issue with the NMI in general. When I run the above program and scroll the video (e.g. LIST), the screen gets scrambled and after a while the LM80C behaves erratically.

I suspect this is due to the NMI interrupting just when the firmware is accessing the VDP; it doesn't matter that all the VDP ops are enclosed in DI and EI, it's a NMI and you can't stop it. Is that correct?

I tried to remove all VDP writes in the routine (except of course the INT ACK) and indeed it does work normally. So I deduce this means that only one routine can use the VDP: the NMI routine or the outside-NMI.

In this scenario I think that the NMI hook is still useful for games when an hypothetical game loop is all within the NMI routine. For raster tricks, the NMI could be used as a reference for CTC and make all video updates in the CTC-triggered interrupt which is maskable.

What are your comments?

10 FOR T=&H9000 TO &H9037
20 READ B:POKE T,B
30 NEXT
40 SYS &H9000
50 END
1000 DATA 17,6,144,195,23,38,245,213
1010 DATA 229,30,246,62,7,205,19,6
1020 DATA 33,218,2,205,50,144,30,247
1030 DATA 62,7,205,19,6,33,0,5
1040 DATA 205,50,144,30,244,62,7,205
1050 DATA 19,6,205,30,6,225,209,241
1060 DATA 237,69,43,125,180,32,251,201

the source:

org $9000
INSTALL:
   LD DE, MYROUTINE
   JP $2617   ; NMI basic command

MYROUTINE:
   push af
   push de
   push hl

   ld   e, $F6
   ld   a, $07
   call WRITE_VREG

   ld   hl, $02da
   call wait

   ld   e, $F7
   ld   a, $07
   call WRITE_VREG

   ld   hl, $0500
   call wait

   ld   e, $F4
   ld   a, $07
   call WRITE_VREG

   call READ_VSTAT         ; ACK NMI by reading the VDP status register

   pop hl
   pop de
   pop af

   RETN

wait:
   dec  hl
   ld   a, l
   or   h
   jr   nz, wait
   ret

and what you should see:

When you navigate with the cursor keys across the screen, the cursor "vanishes" due to flashing; this makes it difficult to locate where the cursor is landing.

I suggest to set the cursor to "ON" just after a key has been typed (C64 and others does it this way).

I tried to implement this feature myself but I found it difficult due to flashing based on timer rather than a counter.

I have an issue when sending long lines of basic text from the serial port.

When I send more than 90 characters without a carriage return, the LM80C displays spaces and starts to behave erratically. See the right picture, it's the result of sending:

12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

Short lines are ok, indeed nothing is missed as shown in the left picture. It's a basic program sent as a big string, the only difference is that it contains carriage returns. 44850 is the sum of all integers from 1 to 299 -- that's how I make sure nothing was missed).

Can you please verify on the real LM80C? I tried my best to make sure it's not an emulator issue, sorry in advance if it's so. Using latest r39. I'm trying to paste a long basic listing adapted from another machine.

once you open the SERIAL line communication, how do you send/receive data in BASIC ?

when in SCREEN 0 sometimes the characters cross over to the adjacent tile, clearing a row or two of vertical pixels. The bug is evident if you go around with the cursor over a LISTing.

See the attached image:

I think you can save some bytes if you use the Z80 INI instruction in the read sector loop.

I've seen it used in the BIOS of another system, I guess it's what INI was intended to be used for.

E.g this:

LD C, CF_DATA
LD B,0
INI
INI

instead of:

Same for OUTI.