Streaming PCM Audio from SD Card?

[Dacobi]

I now have something that's almost perfect. Both PCM and my menu are smooth, with only a tiny bit of noise and clicks in the PCM.

This is my new update_audio function:

Code: Select all

void update_audio(){

	if(bLoadSound){ //bLoadSound is set to 12 after AFLOW interrupt
	
		if(load_index < (sample_max - 255)){
	
			mLo = (unsigned char)((unsigned short)load_index & 0x00ff);
			mHi = (unsigned char)(((unsigned short)load_index & 0xff00) >> 8);	

		       	__asm__("lda #255");
       			__asm__("ldx _mLo");
		       	__asm__("ldy _mHi");
		       	__asm__("jsr $ff44"); //Call MACPTR
	       	
		       	load_index += 255;
       	
	       	} else {
       		
       			mLoad = (unsigned char)((unsigned short)sample_max - (unsigned short)load_index);
       	
			mLo = (unsigned char)((unsigned short)load_index & 0x00ff);
			mHi = (unsigned char)(((unsigned short)load_index & 0xff00) >> 8);	

		       	__asm__("lda _mLoad");
       			__asm__("ldx _mLo");
		       	__asm__("ldy _mHi");
		       	__asm__("jsr $ff44"); //Call MACPTR
	       	
			load_index = sample_point;
		
			mLoad = (255 - mLoad);
       		
			mLo = (unsigned char)((unsigned short)load_index & 0x00ff);
			mHi = (unsigned char)(((unsigned short)load_index & 0xff00) >> 8);	
		
		       	__asm__("lda _mLoad");
       			__asm__("ldx _mLo");
		       	__asm__("ldy _mHi");
		       	__asm__("jsr $ff44"); //Call MACPTR
	       	
		       	load_index += mLoad;
				       		       	
       		}
       	
		bLoadSound--;
	
		if(bLoadSound == 0){
			while(load_index != sample_index){
				*load_index = cbm_k_acptr();
				load_index++;
		
				if(load_index > sample_max){
					load_index = sample_point;
				}		
			}
		}	       
       	}
}

[Daedalus]

Well! I learned something about the MACPTR call today that I didn't know, and allowed me to finally get what I've been working on to work (Barely, mind you... still lots to do.)

MACPTR is not part of the original C64 code set. It was added early on in the X16 development to support sending blocks of bytes through ACPTR at once. Then a flag was added on that allowed it to work through the VERA's addressing schema (where a single IO port is used through VERA's auto increment feature.)

As far as I can tell, ACPTR sort of stands for "Aio Character PrinTeR" ... or something like that. So MACPTR means "Multiple Aio Character PrinTeR."

Anyway, that flag added to MACPTR is also used by the fat32 implementation's "fat32_read" call and not setting it to zero was stopping me and I couldn't figure out why. What I'm trying to do is make a ROM.BIN file for the emulator that contains no C64 KERNAL code as part of an ambitious project to create a simplified, "UNIX light" shell interface. It won't be popular with the CBM DOS with BASIC crowd, but there's always "X16 Classic" for that.

The first step was start with a blank slate and have only the fat32 library loaded onto ROM bank 1, ROM bank 0 is nothing but my own startup and test code. Reading a test file that contains the text "This is the test file" from the sdcard was the test:

[Dacobi]

an ambitious project to create a simplified, "UNIX light" shell interface. It won't be popular with the CBM DOS with BASIC crowd, but there's always "X16 Classic" for that.

As a huge fan of all things *nix and bash for the past 25 years, this sounds very interesting. I don't understand what you mean by "no C64 Kernel code"? Won't that break compatibility with most other software?

[Daedalus]

As a huge fan of all things *nix and bash for the past 25 years, this sounds very interesting. I don't understand what you mean by "no C64 Kernel code"? Won't that break compatibility with most other software?

Yes, any file load or save code that uses the current KERNAL code (SETLFS, SETNAM, OPEN, ACPTR, MACPTR...etc) will not work. That code would have to be replaced with an API I haven't designed yet, but the new API will more closely model the way more modern file interfaces work, with calls like C's fopen, fread, fwrite, fseek, fclose, etc handled as macros in assembly language.

VERA, and all the other port interfaces would work the way they currently do. The keyboard and mouse tack themselves onto the VERA's VSYNC interrupt and then use software I2C through the SMC just as the X16 currently does.

I've already put in the frame of the interrupt system, and interrupts are running fine. VERA is easy because I can just use the same code... the only real "Hmm... I don't know..." was directly accessing the sdcard and fat32 interface. I still have to work out and streamline all the use cases, but just being able to simply load anything from a file was huge.

[Daedalus]

I feel like I need to explain why I would want to do this.

It's not about not liking Commodore or the C64 or anything like that.

It's about simplicity. One of the arguments for using the discreet DIP chips in the X16 design is "Because I want to be able to understand what the computer is doing." I certainly agree with that sentiment in general. Of course, I also support the use of FPGAs as the future. But not hardware emulation through software... and the FPGA needs to be documented as if it was a "circuit of discreet components" rather than a black box. Someone with familiarity of the original DIPS should be able to look at the FPGA's block diagram and say "Ok, here's the CPU, here's the I2C interface to the keyboard / mouse, here's the interface to the VERA, etc."

But that simplicity argument is only used for the hardware. The SOFTWARE chosen is an unwieldy monolith from the '80s that's not only proprietary, but difficult to understand at the same time. I don't think there are too many people who actually understand how it actually works at a fundamental level. I've been studying it for months and barely understand any of it.

A retro computer like this needs to be simple at the basic level, a few pages of documentation should be enough to give you a firm grasp on all it's core components so that a programmer can then effectively write software for it, confident that that software will actually work. complex issues like interfacing files, from opening them to streaming blocks of data from them into the audio engine should be clear and deterministic. A programmer shouldn't have to dredge through 30 year old information trying to pick out what still works and what has ultimately been replaced but still has the same vague name associated with it.

[Dacobi]

My thoughts regarding compatibility was just that I think it would drastically reduce the number of useful use cases if all software would have to be written specifically for your shell. It would almost turn the X16 into a completely different computer.
On the other hand if you implemented maybe just a subset of the most commonly used C64 Kernel functions so that most X16 software could be launched from within your shell, it would truly be an awesome system.

Edit: Again this was just my thinking. I don't really have a grasp of how many C64 Kernel functions would have to be implemented for this to work or how hard it would be to implement.

Edit2: Another thought was whether it's possible to have a setup with both your shell ROM and the normal ROM and then somehow switch between them when launching a normal X16 program?
I don't know the first thing about how ROM addresses etc work on the x16 so don't know if this could be done.

[Daedalus]

You have a solid point that I really hadn't considered. While it would be pretty easy to make an "X16" version and a "lux" version of any software, having an "X16" compatible mode that can run "most" X16 software directly would be super useful.

"lux" is what I'm calling my system. It stands for "Light Unix Command Shell." (The C and S make a homophone of "x.") Heh. I'm so clever, right? Yeah, I know I'm a dork.

The vast majority of what "X16 software" you're referring to is games or other standalone products written in C or assembly. These are programs that take control away from the KERNAL and implement their own VERA mechanics and their own interrupt routine. The other thing they might do is use CHROUT to write text to the "standard screen" instead of interfacing with VERA themselves, and GETIN to not bother with doing the keyboard themselves.

What the KERNAL does in the X16 that's currently not practical to "just do yourself" in your own C or assembly program is interface to the SDcard to access files. I would expect that 90% of that uses only SETLFS, SETNAM, and LOAD and even in the X16, those just ultimately use fat32, which is the same code I'm using. All I have to do is provide the same call addresses, then have shell routines.

Then there are interrupts. I've implemented a more robust system that doesn't make you intercept the interrupt handler at the interrupt level, but rather provides hooks to all the interrupt sources that you can use ala carte. The default hooks are just stubs that have nothing but an rts instruction. All I would need to make an "X16 compatibility mode" is have a "base hook" that intercepts the interrupt at the start and would make the programmer then handle it all as they do now.

[Dacobi]

"lux" is what I'm calling my system. It stands for "Light Unix Command Shell." (The C and S make a homophone of "x.") Heh. I'm so clever, right? Yeah, I know I'm a dork.

I like it : )

What the KERNAL does in the X16 that's currently not practical to "just do yourself" in your own C or assembly program is interface to the SDcard to access files. I would expect that 90% of that uses only SETLFS, SETNAM, and LOAD and even in the X16, those just ultimately use fat32, which is the same code I'm using. All I have to do is provide the same call addresses, then have shell routines.

I would prefer to have OPEN/CLOSE, CHKOUT and ACPTR/MACPTR added to the list since my game uses them ; ) and I'd love to launch it from a lux command line.
Although I would almost certainly create a lux version.

How would you handle the joysticks scanning routine and keyboard Up/Down interrupt?

[Daedalus]

How would you handle the joysticks scanning routine and keyboard Up/Down interrupt?

The same way it's handled now. In the X16, that is all code added onto the KERNAL, The joysticks are simple, merely pulling data in from the VIA chip a few bits at a time. The keyboard/mouse interface is PS/2 that's decoded by the SMC (System Micro Controller) that's an Atmel part connected to the X16 through a few VIA pins, the software side is a software I2C interface that's polled during the VSYNC interrupt handler 60 times per second. None of that is in the proprietary part of the KERNAL, and is (Like the fat32 library itself.) licensed with a combination of BSD 2 clause and 3 clause, which I'm free to use providing I adhere to the conditions.

[Edmond D]

You have a solid point that I really hadn't considered. While it would be pretty easy to make an "X16" version and a "lux" version of any software, having an "X16" compatible mode that can run "most" X16 software directly would be super useful.

"lux" is what I'm calling my system. It stands for "Light Unix Command Shell." (The C and S make a homophone of "x.") Heh. I'm so clever, right? Yeah, I know I'm a dork.

I like the idea of a light Unix type shell that would be able to run most standard X16 programs, but I'd suggest a different name for two reasons:

1) Calling something Unix or Unix like is going to set the expectations high. Saying it can run "most" X16 programs is going to make those who can't run a certain particular one a little rowdy. When lux doesn't deliver (technical or otherwise) I think the backlash is going to be high.

2) In college, we had a Honeywell CP6 system - https://en.wikipedia.org/wiki/Honeywell_CP-6. It was derogatorily called CP-SUCKS.

Perhaps "ACE OS" - Alternate Commander Execution Operating System?

That being said, please keep your efforts going. Most of the X16 fanbase will be tolerant I think, as an X16 is a connoisseur (niche?) platform, and those who don't like it aren't going to be using it at all.