-
Cursor management improvements
09/08/2019 at 17:32 • 0 commentsI've worked hard to check and fix the code that manage the flashing cursor on the screen. I did it because I noticed that when running a program in a non-direct mode (i.e. when the program didn't need inputs from the user), the cursor was always flashing on the screen.
I worked a lot and (hope I have) fixed it by checking the mode of working of the interpreter: now the cursor is on the screen only when in direct mode or when the program ask some input by the user (i.e. using the INPUT command).
The new release is marked 2.1a.
I also added a new BASIC program, WA-TOR, a simulator of preys and predators in a fictional world. Enjoy it.
-
Testing graphics & sound
08/25/2019 at 21:29 • 0 commentsWhile I'm working on new mods to my computer (I started works to connect an external keyboard from an old computer), I wasted a couple of minutes of my spare time to try mixing some things I tested previously. I took the sprites test and combined it with some sounds and a boincing text to get this:
Very 8-bit-ish, isn't it? :-)
Have a nice day and see you soon.
-
Sound made easy
08/19/2019 at 16:17 • 0 commentsAfter a while (summer holidays) I got my hands on my computer again. This time I added a couple of commands to make the sound management easier. I coded a while and now VOLUME and SOUND are ready to be used.
VOLUME has a very simple sintax and just gets 2 params: the first one is the audio channel, the second one is the volume level. The channel can be an integer in the range 0~4: 1, 2, & 3 point to the corresponding channel (1->A, 2->B, 3->C) while 0 stands for “every channel”, meaning that it’s like a global setting. The volume level is an integer in the range 0~15, where 0 is for OFF and 15 is for MAX volume level.
SOUND required more work because I had to manage 3 different user params: the channel, the frequency and the duration. The first one is clearly understandable: it chooses the channel used to reproduce the sound. The second one sets the frequency of the tone to be reproduced, in the range 0~4,095. We have to pay attention that this value doesn't represent the real frequency of the tone but it is just an index that has some sort of correlation between its value and the frequency. It gives to users the feeling that higher numbers mean higher tones, the same way of working of some old computers, i.e. my C16 did the same way. The last param sets the duration in hundreds of seconds, and this was possible thanks to the timer I implemented in the firmware using a counter of the Z80 CTC.
The new statements are available in the R2.1 release.
-
Let's make some sounds
07/14/2019 at 17:53 • 0 commentsAfter a short period of absence I got my hands back on LM80C. I wired up the Yamaha YM2149F (but this is valid for the GI AY-3-8910, too: they are almost identical. I got the first one with a kit of ICs where the seller on eBay said he was selling an AY while sent me the YM) programmable sound generator (PSG) that I bought some time ago, and then I connected the audio output to the RCA mono input of my TV set, getting the first whimpers of my home-brew computer.
In the video you can hear that there is a complex audio: in fact,in this first test I activated all the 3 analog channels: channel A is reproducing a fixed tone; channel B is reproducing a fixed note mixed with some white noise; channel C is reproducing a tone using an envelope mode (saw tooth). To get the sound, I simply connected the 3 output channels to the mono audio input of the RCA port of my TV set.
To obtain this result I had to add another address decoder to my circuit, since the original AY-3-8910 from General Instrument (and the YM2149F clone from Yamaha, of course) was made to work in conjunction with the old CP1600 microprocessor from GI, that used 3 lines to set the operating modes of the PSG. Since the PSG settings are redundant (there are several settings that get the same effect), it was the same manufacturer that suggested to pull up one of the setting lines and use the other two. Thanks to this, we can use the just 3 signals: one for the chip selection, one to choose between register and data modes, and the last one to choose to read from/write to the PSG.
The PSG is a register-based sound processor: this means that the CPU has just to send the data to the PSG, that stores these infos inside its registers and then use them to generate the sounds, so that the CPU doesn't have to take part in the process anymore once the PSG starts its work. But I discovered an issue concerning the way we choose the register: in the datasheet registers go from 0 to 7 and then from 10 to 17 but in reality they go from 0 to 15. I didn't investigate why but to choose the register 10 I had to send the value "8", and so on. In the video you can see the list of the program I used to get the sounds you hear in the video: as you can see, there a lot of OUTs: outputting a value to port 64 selects the write mode to the register pointed by the passed value, followed by an output to port 65 to send the value to be written into such register.
Once I was able to get some sounds from the PSG, I added a couple of statements to the NASCOM BASIC to write to/read from the registers of the PSG. Firmware release R2.0 now contains the SREG command and the SSTAT function. The first one is used to write a byte into a specific register while SSTAT is used to read from any of the registers.
The new firmware with the updated schematic is available at my Github repository.
-
VREG, VSTAT, and LOCATE statements
06/20/2019 at 16:29 • 0 commentsI've worked hard to add some new useful statements to the BASIC interpreter.
These commands are very useful when working in graphics because:
- VREG: this command writes a value into a specific VDP register. Usage: VREG reg, val, where "reg" is the register where to write to (in the range 0..7), while "val" is the value to write (0..255).
- VSTAT: this function returns the current value of the VDP register status, so the user can look for sprites collisions and also for the number of the 5th sprite on a row (the VDP cannot visualize more then 4 sprites at the same time on the same row). Usage: VSTAT(x), where "x" is any integer number. The returned value is in the range 0..255.
- LOCATE: this command positions the cursor at a specific video cell. Usage: LOCATE X,Y, where "x" is the horizontal coordinate and "y" is the vertical coordinate. "x" must be in the range 0..(width-1), where width is the screen width of the current video mode. I.e.: in mode 0 (text), width is 40, so "x" can only have a value between 0 and 39. Similarly, "y" must be comprised between 0 and the (height-1) where the screen can goes from 0 to 23 (the height is 24 chars both in text and in graphics 1 modes).
I've also completed the 8x8 pixels font by adding the missing chars in the first release of the charset and expanded the max. default string size to 100.
The files of the new firmware, marked R1.9, have been uploaded on my GitHub repo.
-
VPOKE & VPEEK
06/15/2019 at 14:32 • 0 commentsIn the last days I've worked to expand the commands and functions of NASCOM BASIC by adding VPOKE & VPEEK.
VPOKE is a command that, as you can understand by the name, lets you write a value into a specific VRAM cell. VPEEK is a function that, obviously, reads a byte from a VRAM cell. These two are necessary because the LM80C firmware manages the cursor through an interrupt raised by a timer of the Z80 CTC: due to this way of working, at regular intervals the main code flow is interrupted and the cursor management code is executed. Since the VDP has a data buffer for reading and writing from/to the VRAM and since it also has an auto increment counter that, after the first read/write, automatically increments the address pointer, if you use OUTs and INs to write/read to the VRAM, you will experience glitches and graphical artifacts because the read/write operation you are making could be interrupted in the middle of its course by the cursor manager: this will lead to collisions between the two codes that make a VRAM access through the VDP and unpredictable side effects, like random chars that could appear on the screen or wrong data written into memory.
VPOKE & VPEEK avoid this, since they disable interrupts before accessing the VRAM and re-enable them after they did their work.
The new firmware is marked R1.8 and is available for download from my Github repo.