Forums

During this years coding competition, I got my entry to run on the SC-3000 with a BASIC IIIa / BASIC IIIb cartridge.

As a demo, I thought I'd have a go at porting a previous project to run like this. A tool I'd originally written to play VGM music on an 8-bit AVR micro-controller.

There seem to be ocassional slow-downs on some pieces of music, which could be caused by the compression I added for the AVRs being a bit much for the Z80 to keep up with. There are also some limitations on the size/complexity of the music, as the compression scheme was intended for a chip with only 8K of flash.

I've also added a basic bar-graph visualization.

The code is up on Github for anyone that wants to give it a try:
https://github.com/JoppyFurr/VGM-TapePlay

I'll also attach a pre-build copy with a tune from Lemmings.

From the BASIC prompt, the following steps are used to get it running on real hardware:
1. `LOAD`
2. Play the .wav file
3. `CALL &H9800`

Cheers,
Joppy

VGM-TapePlay-screenshot.png (360 B)

screenshot

VGM-TapePlay (Lemmings).zip (22.65 KB)

Example using a Lemmings tune

Having now tested this on both my SC-3000H, and also on a Master System with a flash cart: It's exposed a difference I was unaware of between Mode-2 on the TMS9929a is my SC-3000, and Mode-2 on the Master System's VDP.

In Mode-2, the screen is broken up into three 'slices', where the 8-bit tile index is given two extra bits based on which third of the screen the tile is being placed on. The extra bits are +0x000, +0x100, +0x200, for the top, middle, and bottom thirds of the screen.

On TMS9929a Mode-2, there are bits in registers 3 (colour-table address) and 4 (pattern-generator address) which can be used to mask out these extra position-dependent bits. This allows the entire screen to share a single 256-entry pattern table, which is what I did in my ROM.

On Master System Mode-2 however, the configurable mask does not appear to exist, meaning that to share the same tiles over the whole screen, the table needs to be loaded into three different addresses in VRAM.

To enable compatibility with the Master System, I'll make a change on my GitHub to write these duplicate of the tables. I will however leave the attachment to this thread as-is, as it's potentially useful as a way to tell apart the different VDPs.

I've just pushed an update to the GitHub repo.

The slowdowns were not caused by the compression, but by missed interrupts. It seems that polling doesn't always catch them all, which could be the clear-on-read mechanism doing the clear without ever actually reporting the interrupt.

I've now changed the modified version of crt0_sg to use interrupt-mode 2. In this mode, the I register can be used to set the upper byte of an interrupt vector table, which can be placed in RAM.

This fixes the slowdowns, so music is now sounding better on real hardware. Having real interrupts also means that I can link against the normal version of SGlib, instead of having a special version that uses polling.

JoppyFurr wrote

On TMS9929a Mode-2, there are bits in registers 3 (colour-table address) and 4 (pattern-generator address) which can be used to mask out these extra position-dependent bits. This allows the entire screen to share a single 256-entry pattern table, which is what I did in my ROM.

On Master System Mode-2 however, the configurable mask does not appear to exist, meaning that to share the same tiles over the whole screen, the table needs to be loaded into three different addresses in VRAM.

Is this because the SMS VDP is an evolution of the TMS9918 instead?
I mean, does these bits work on the SG-1000?

What we know is only this:

Quote

Register $03 - Color Table Base Address
This register defines the VRAM location of a table which defines foreground/background colours in some TMS9918a modes. For Mode 4 on the SMS1 VDP, all bits should be 1 to give normal operation.

The only TMS99xx system I have to test on is the PAL SC-3000.

I found out about this behaviour in a text document by Sean Young. The document seems to target the tms9918a. My best guess is that it is common across that series of chips, just not included in Sega's VDP.

http://bifi.msxnet.org/msxnet/tech/tms9918a.txt

I have had a look at the TI documentation for the chip, the "Data Manual". In the Graphics II Mode section, it sates for those two registers "The LSBs must be set to all 1s", so it appears that this was not an officially documented feature.

JoppyFurr wrote

I have had a look at the TI documentation for the chip, the "Data Manual". In the Graphics II Mode section, it sates for those two registers "The LSBs must be set to all 1s", so it appears that this was not an officially documented feature.

So this likely explain why this feature is not present in the SMS VDP.
Too bad, it would have been handy.

Author	Message
JoppyFurr Joined: 11 Mar 2018 Posts: 66 Location: New Zealand	Loading VGM music onto the SC-3000 from tape Posted: Thu Mar 28, 2024 12:31 pm
	During this years coding competition, I got my entry to run on the SC-3000 with a BASIC IIIa / BASIC IIIb cartridge. As a demo, I thought I'd have a go at porting a previous project to run like this. A tool I'd originally written to play VGM music on an 8-bit AVR micro-controller. There seem to be ocassional slow-downs on some pieces of music, which could be caused by the compression I added for the AVRs being a bit much for the Z80 to keep up with. There are also some limitations on the size/complexity of the music, as the compression scheme was intended for a chip with only 8K of flash. I've also added a basic bar-graph visualization. The code is up on Github for anyone that wants to give it a try: https://github.com/JoppyFurr/VGM-TapePlay I'll also attach a pre-build copy with a tune from Lemmings. From the BASIC prompt, the following steps are used to get it running on real hardware: 1. `LOAD` 2. Play the .wav file 3. `CALL &H9800` Cheers, Joppy VGM-TapePlay-screenshot.png (360 B) screenshot VGM-TapePlay (Lemmings).zip (22.65 KB) Example using a Lemmings tune

JoppyFurr Joined: 11 Mar 2018 Posts: 66 Location: New Zealand	Posted: Fri Mar 29, 2024 1:15 am
	Having now tested this on both my SC-3000H, and also on a Master System with a flash cart: It's exposed a difference I was unaware of between Mode-2 on the TMS9929a is my SC-3000, and Mode-2 on the Master System's VDP. In Mode-2, the screen is broken up into three 'slices', where the 8-bit tile index is given two extra bits based on which third of the screen the tile is being placed on. The extra bits are +0x000, +0x100, +0x200, for the top, middle, and bottom thirds of the screen. On TMS9929a Mode-2, there are bits in registers 3 (colour-table address) and 4 (pattern-generator address) which can be used to mask out these extra position-dependent bits. This allows the entire screen to share a single 256-entry pattern table, which is what I did in my ROM. On Master System Mode-2 however, the configurable mask does not appear to exist, meaning that to share the same tiles over the whole screen, the table needs to be loaded into three different addresses in VRAM. To enable compatibility with the Master System, I'll make a change on my GitHub to write these duplicate of the tables. I will however leave the attachment to this thread as-is, as it's potentially useful as a way to tell apart the different VDPs.

JoppyFurr Joined: 11 Mar 2018 Posts: 66 Location: New Zealand	Posted: Fri Mar 29, 2024 6:30 am
	I've just pushed an update to the GitHub repo. The slowdowns were not caused by the compression, but by missed interrupts. It seems that polling doesn't always catch them all, which could be the clear-on-read mechanism doing the clear without ever actually reporting the interrupt. I've now changed the modified version of crt0_sg to use interrupt-mode 2. In this mode, the I register can be used to set the upper byte of an interrupt vector table, which can be placed in RAM. This fixes the slowdowns, so music is now sounding better on real hardware. Having real interrupts also means that I can link against the normal version of SGlib, instead of having a special version that uses polling.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Fri Mar 29, 2024 1:02 pm
	JoppyFurr wrote On TMS9929a Mode-2, there are bits in registers 3 (colour-table address) and 4 (pattern-generator address) which can be used to mask out these extra position-dependent bits. This allows the entire screen to share a single 256-entry pattern table, which is what I did in my ROM. On Master System Mode-2 however, the configurable mask does not appear to exist, meaning that to share the same tiles over the whole screen, the table needs to be loaded into three different addresses in VRAM. Is this because the SMS VDP is an evolution of the TMS9918 instead? I mean, does these bits work on the SG-1000? What we know is only this: Quote Register $03 - Color Table Base Address This register defines the VRAM location of a table which defines foreground/background colours in some TMS9918a modes. For Mode 4 on the SMS1 VDP, all bits should be 1 to give normal operation.

JoppyFurr Joined: 11 Mar 2018 Posts: 66 Location: New Zealand	Posted: Fri Mar 29, 2024 11:47 pm
	The only TMS99xx system I have to test on is the PAL SC-3000. I found out about this behaviour in a text document by Sean Young. The document seems to target the tms9918a. My best guess is that it is common across that series of chips, just not included in Sega's VDP. http://bifi.msxnet.org/msxnet/tech/tms9918a.txt I have had a look at the TI documentation for the chip, the "Data Manual". In the Graphics II Mode section, it sates for those two registers "The LSBs must be set to all 1s", so it appears that this was not an officially documented feature.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Sat Mar 30, 2024 5:31 pm
	JoppyFurr wrote I have had a look at the TI documentation for the chip, the "Data Manual". In the Graphics II Mode section, it sates for those two registers "The LSBs must be set to all 1s", so it appears that this was not an officially documented feature. So this likely explain why this feature is not present in the SMS VDP. Too bad, it would have been handy.

Forums

View topic - Loading VGM music onto the SC-3000 from tape