Can’t read AppleII 8-bit Data Bus with Blue Pill

[Very.Von]

@Bakisha I tested with both variations. I assume you meant PB_6 (BUS00) not PB_5.

Code: Select all

while( (GPIOB->IDR) & (1<<6) ) {                            // output is always 00000000 00000000 00000000 00000000
while(digitalReadFast(PB_6)==LOW){                          // output is always 00000000 00000000 01111111 00111000 

I double checked the wiring to make sure it matches up with the defines. Looks solid.

I'm really starting to think this is a 5V issue and some sort of circuitry or voltage divider is needed for accurate reading of the databus.

[dannyf]

looks like the display routine is doing its job.

so two questions:
1. how do you know that those pins are changing states?
2. how do you know that the state changes on the pins are getting to the input data register?

for #1, you should try to see if you can control the state of the pins.
for #2, you should see if the states of the pins are reflected on the stm32 - maybe there are connectivity issues for example.

[ag123]

@ag123 thanks for bridge chip suggestion! As I understand it PortB is 5V "Tolerant" - does this mean I should have external 5V pull-up's on the pins?

Some circuits are 'open collector', if that is indeed the case it may need a pull-up to get the signal. That may be worth trying out, but it'd be good to check datasheets to confirm.

Sometimes I get lazy and simply use a higher resistance e.g. 10k and connecting 5v to STM32's '5V tolerant' pins, accordingly, STM32 uses diodes and resistors to bypass the excess voltages, hence it can't take too much currents, to prevent overheating damage a bigger resistance helps. For low MHz, I think rather it may work with even rather high resistance pull-ups. Otherwise, maybe keep reducing trying 4.7k 3.3k and maybe even down to 1k

of course, if you want to be paranoid you can use a 74LVC series to bridge 5v output into 3v inputs on STM32. I'd guess even comparators may work e.g. LM239, LM339 etc.

the 'bridge' chip e.g. 74HCT245, actually, anything in the 74HCT families would do, is to bridge 3.3v cmos logic (output) to 5v TTL logic (input).
there are 'level converters' but that I find 74HCT series the most convenient in terms of the small foot prints , and 74HCT chips are fast !

[Bakisha]

So appears to be working?

My mistake, i missed

Code: Select all

value <<= 1;

Unfortunately, until you measure bluepill's interrupt latency i can't say in what point in time you are reading data bus. But don't forget that you have info on BUS01, DS and RW also, so you can guess when the reading is done.
I don't think that bluepill reading TTL bus is a problem (but writing is).
Try to get CPU at known state, run some simple program like:

Code: Select all

         LDA $#FF
loop:    STA $C0E0    //  4 cycles
         JMP loop     //  3 cycles

Maybe add some pin toggle as a test for digital analyzer.
Maybe set bluepills interrupt priority.
Try to compile with O1,O2,O3...
Or add some hardware (HCT) latch and read it with bluepill.

[Very.Von]

Try to get CPU at known state, run some simple program...

I've never run asm directly in a sketch but I'll look for examples, I've seen it in other people's code.

Maybe add some pin toggle as a test for digital analyzer.

Good idea, this should be a good exercise and I can use the oscilloscope.

Maybe set bluepills interrupt priority.

I thought interrupt would be the fastest way... but now I realize there's no way to set interrupt priority in this library?
And this has led me to another idea that is working... (see below)

Try to compile with O1,O2,O3...

Setting optimizations O1, O2 & O3 within the Arduino IDE doesn't seem to effect loop performance of the code below. I can verify the build flags are present in the build output, but no effect I can detect in the code.

Or add some hardware (HCT) latch and read it with bluepill.

^^^ Last one is what I'm trying most to avoid

However! When I use code like this without interrupts:

Code: Select all

void loop() {
    
    while (true) {
        
        while( ! ((value = GPIOB->IDR) & (1<<3)) ) {
            counter++;            
        }
        if (counter != previous_counter) {
          Serial.write("Counter = ");
          Serial.println(counter);
          displayBits32(value);
          counter = 0;  previous_counter = 0;          
        }
    }

}

I'm getting valid data! Normally the "counter" value is 1, 2 or 3. I've never seen 4. This leads me to wonder where the overhead is coming from. If the sampling rate is anywhere near 72Mhz, and DS is low for at least 450ns, then how could we only sample the register 2 or 3 times???

Some sample output (0x00, 0x01, 0xFF)

Code: Select all

Counter = 3
00000000 00000000 00000000 00111000 
Counter = 3
00000000 00000000 00000001 00111000 
Counter = 2
00000000 00000000 11111111 00111000 

To get faster sampling, I think i'll have to drop the convenient Arduino IDE toolchain and look towards something more bare metal like platformio/toolchain-gccarmnoneeabi as I saw a project like BlueSCSI uses.

[Bakisha]

That code was for Apple 2.
I am not familiar with its hardware , but code should be same:

code1.jpg (46.84 KiB) Viewed 2938 times

I can't say much about execution time of code generated with compilers, but i know that it's never one instruction per one CPU cycle.

Anyway, by looking at datasheet you posted in first post, i still think you need to experiment and see what timings give you predictable result.

[Very.Von]

That code was for Apple 2.

OH!! Hahaha, got it yes

Anyway, by looking at datasheet you posted in first post, i still think you need to experiment and see what timings give you predictable result.

Yes totally agree with those timings. It's the bare metal timings on the bluepill that I need to learn now! Thank you for your suggestions.

p.s. about the lines in your drawing about "enter interrupt" and "read data" I tried that technique many times and adjusting things. Always the read was too late. It's like the interrupt latency is too high to capture within 450ns, and I couldn't figure out how to set interrupt priority in this framework.

[Bakisha]

Just an a idea for experiment:
Attach interrupt on RW falling, and if DS is low grab data? It would trigger on every write, but writes on 6502 is not so often. As long as ISR is shorter than 4µS, it should be working for latency up to 800, maybe 900nS.

Something like:

Code: Select all

 attachInterrupt(digitalPinToInterrupt(RW), DS_ISR, FALLING); 

volatile uint32_t value=0;
volatile bool data_ready = false;

//  ISR
void DS_ISR()
{   
   if((GPIOB->IDR)&(1<<3)==LOW){ 
    value = GPIOB->IDR;
    data_ready = true;    
    }
        
}
void loop() {
if (data_ready){
data_ready = false;
displayBits32(value);
}
}

[Very.Von]

Just an a idea for experiment:
Attach interrupt on RW falling, and if DS is low grab data? It would trigger on every write, but writes on 6502 is not so often. As long as ISR is shorter than 4µS, it should be working for latency up to 800, maybe 900nS.

Thanks for that. I'm going to see how far I can get without using interrupts. I'll report back when I have some more progress.

[dannyf]

It's like the interrupt latency is too high to capture within 450ns

20 - 40 ticks for isr overhead - depending on lots of factors. at 72Mhz, that means 300-600ns. so I think you have a fighting chance, if you read the input data register rightaway in the isr.

one way to measure the isr is to read a counter (DWT for example), trigger an isr (by setting a flag) and within that isr, read the counter again. the delta between the two readings is your isr overhead / latency.