_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Updates to come! But first...



I forgot to reply to this. I actually really want to use BCPL as my higher level language for my editor. We'll be talking

Now! Attachments! Registers! Errors! Confusion!

As shown below, I am able to use the PIC to load from the SD card again, but this time it also includes code. And that code is running! Kind of! The picture looks great, I jump to the start of code (which is included with the picture data but in the V-Blanking area), and it has the ability to blink a pixel in the top corner. That's a sign of life But that's all it's doing. In fact, I had my "printchar" subroutine copied over to the code, and although the simulator shows the 'A' character, my actual hardware does not.

YET it still does the blinky pixel AFTER trying to print the character. Huh? That makes me think there is something I really don't understand about the '816 in native mode. I *feel* like the registers are being cleared or corrupted or something. I can JSR and RTS just fine, anything more complex and it gets weird. My first instructions look like this:



The REP #$08 turns off decimal mode, and the SEP #$34 keeps it in 8-bit mode with interrupts off, right?

The rest of the code is really quick:



Assuming that my "printchar" does what it should do (given that the simulator seems to work fine), I don't see what could be an issue besides a hardware/register level misunderstanding.

Any thoughts on why the '816 would be acting funny to more complex code? I'm open to suggestions. My full assembly code is attached (ignore the picture data at the top), and the C code is for the PIC in case you were wondering.

Thanks everyone!

Chad

What is DBR (data bank register) set to? Unless you've changed it somewhere, it's set to 0 by reset.
My guess is that you have PBR=$3e (the bank your code is in), maybe set by a JSL, and DBR=$00 (not modified after reset).
IF this is true, your JSR absolute and branches will work as expected, bur your absolute data references will be happening in bank 0.


Not a problem but an easier way if you have some direct-page (formerly zero-page) space available.

I don't know about 816-specific issues but I do highly recommend a logic analyser coupled with hoglet's decoder for diagnosing this kind of thing if your actual hardware is not matching your simulations. Given the data bus state at the falling edge of the clock it will tell you exactly what the CPU is doing, and you can spot cases where it's not doing what you expect, and get clues about whether it's reading unexpected data from memory or I/O, or whether your code is just not doing what you expect it to, etc.

You could even feed the data from your simulator into the decoder to check the simulator is behaving correctly, without needing the logic analyser, perhaps.

leepivonka, thank you thank you thank you! Hot dog, it works! See attached pictures Wow, I *really* had a fundamental misunderstanding there. Thank you for seeing that, so awesome to see it doing complex functions now! If I saw you in person I'd hug you!

This is what I inserted:



And so the next (and last) thing I want to get rolling right now is the keyboard. And it's not working, probably because the interrupts are doing something very similar. The keyboard works for my fallback monitor, but not in my new demo code, probably for the same reasons: a register is not set correctly. Will be continuing to work on that. Once the keyboard is functioning then I can start to rest, or perhaps just push harder

Thank you again leepivonka!

Chad

Whelp, that was fast! Keyboard is now working (mostly) as expected, yay! I just changed the addresses in my ISR from absolute to absolute-long, and copied my fallback monitor VIA code into the demo code. BAM, that did it!

So many more hardware things to get working. The keyboard isn't great for Tetra right now, but that's all software. After that is the vertical scrolling and then getting my latest demo code with the editor to work.

After all that I want to try to get the PIC to speed up it's reading from the SD card. It currently takes about 1.5 minutes to load 128KB from the SD card. That's a LONG time. Some things I'm considering is speeding up the PIC from 4 MHz to 8 MHz, and perhaps running PIC assembly code directly rather than through a C compiler. I'm super scared to even *touch* the darned thing since I've been fighting with it for a week now. I'm happy it's working but golly what a ride!

Y'all have been seeing a whole bunch of Link today I guess it's that or the Gouldian Finch, should probably try that too soon. Just wanted to show off those colors! I'm really contemplating doing the little color change George suggested, that sounds like it would be really neat.

Again, thank you all for your help and support. I really couldn't have done this without y'all. This is YOUR victory too!

Will update more, later.

Chad

EDIT: I couldn't help it, so I put the Gouldian Finch on there now.

More updates! Included are some pictures and my PIC code, my Demo code, and my Verilog code.

This morning I worked on vertical scrolling. Golly I had some misunderstandings there too it seems! I was able to fit vertical scrolling for *text* in the CPLD, but I couldn't do it pixel by pixel as of now. Though, that's good enough for now I suppose.

Then I wanted all of my latest demo code to work, but I ran into trouble. Did you know that the '816 has "reserved" spaces in $FFE0-$FFE3 and $FFF0-$FFF3 which are completely unused? What a perfect spot to stick some random variables to squeeze my bootloader code in even more. WRONG! Those little buggers cost me some hours. As soon as I got the code out of there, everything was fine again. Now you know!

Last thing, George and I were talking last night and he mentioned some places where I could optimize my SD card code on the PIC. I did that and doubled the PIC's internal clock speed, and it now loads 128KB in about 30 seconds! That's a third of the time from before! Thank you again George, super awesome upgrades.

What I would really like to do next is somehow fix my bodges more properly. One of the pins on a SMD chip broke off, and it has been *very* difficult resoldering the darned thing three times now. I think my plan is to pull the chip off the board, solder it down entirely, and then just scrap some traces and maybe run a few bodges on non-lifted pins. I'd also like to add a blinky 'loading LED', something that blinks while I'm waiting for it to load. The way I have it set up, the CPLD can only display a black screen while the PIC is spoon-feeding the '816, so having something say "hey, it's ok, I'm working on it" would be nice. I have a spare pin on the PIC for this, but trying to add it somewhere on this board would be physically difficult.

Alright, now I gotta do real-world work again. But at least now I can demo this board to our Math and Engineering Club. Thank you again everyone!

Chad

I know they're marked reserved but didn't realise they could not be write/read as normal RAM. Seems odd...



FWIW: I run the ATmega on my Ruby board at 16Mhz and the SD (SPI) clock is 8Mhz, so I can read/write the SD card at 1MB/sec. give or take. Sadly the transfer over to the 65xx side is much slower at about 33KB/sec but that's more than good enough.

So why is the PIC so slow with SPI reads off an SD card?

However - still looking good!

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

You can prove me wrong Gordon, I'm fine with that. It could have been some other issue, but I went from that RAM location to another and it was a world of difference when dealing with the IRQ interrupts.



Well, a few reasons. The PIC has an SPI-ish hardware feature that I failed to understand in time to get the board printed and soldered. It might increase the speed a bit there, but I'd have to do some serious bodges. Also I'm running off the internal 8 MHz clock, where the PIC can go much faster than that with an external source, but I needed that clock pin for the databus. Also I'm running C code through 'sdcc' which is an off-brand of the official PIC C IDE, so it is terribly unoptimized. I haven't yet learned PIC assembly to make it much faster.

All of those things coupled together make for a much slower experience. Still, even when I run an SD card module directly through a VIA, I find that it is still terribly slow in comparison to what I always hear about. Maybe they just don't like me When I make my next board revision, I'm thinking of squeezing the DIP-40 PIC16F887 on there to get more pins so that I can run with an external clock and also use the SPI hardware to the fullest. I should also learn PIC assembly...

Thanks Gordon!

Chad

Exactly the reason I'm using an STM32L073 - 64 pins and I'm using all but half a dozen, two of which are clock inputs. But it needs 24 for the address and data, five more to interface the DMA, and others for the SPI and PS/2 ports. And the qfp64 has eight or nine power/ground pins.

My as yet unanswered (and at the moment, largely unanswerable) question is whether to hand off graphics to the STM or let the 65C02 do it; 65C02 is running at 2.5MHz but has full time access to the ram (unless the DMA takes over) while the STM is running 32 bits at 32MHz, but can only have 6us at the end of each line and 730us at the end of each field. An interesting question...

I'm out of date on the PIC but I worked with them in the past: I had a boss who insisted on machine code for everything (because you don't get mistakes!) and trust me, it did my head in. But later I used both the PIC compiler free version and the SDCC; the SDCC was largely awkward because of the memory model, and the PIC compiler (at the time) I felt was actively unoptimised - it generated much better code if you paid up. But I think they've changed since then.

Neil

One approach that would reduce the size of PLD required would be to have a smaller number of bytes handled per activation ... for instance, have up to 16 bytes handled, stopping when the low nybble of the source address overflows to $0. The nybble address could be in a different register than the A4-A11 register, with the higher address autoincrementing, so that the store to the nybble source address register could launch the operation, and two bytes of high address registers gives a memory address range of up to 1MB.

If up to 32 clocks of bus mastering before an interrupt can be handled is acceptable, that approach wouldn't require special handling of interrupts within the mini-blitter.