The sources for the DE0 nano Quartus project can be downloaded from here.
The Quartus project should compile with 13.1 or above. The rom0 memory is set to load "both.hex" which is BASIC2 and a slightly hacked version of OS1.2 (the main difference is to skip checking interrupts for the user via).
The assembler sources are in the /software directory and can be compiled using the cmp.sh and cmpOS.sh scripts. You'll need cc65 version V2.14.0 or later
Saturday 29 March 2014
Friday 28 March 2014
FPGA/BBC Now boots and runs basic
Well I've got a bit further on with the FPGA project today. I managed to get it to boot to BASIC and run long enough to type in simple test programs.
There were a few problems of my own that I had to overcome...such as spotting some address selection logic that I'd commented out for some unknown reason and some dodginess with my SPI slave implementation (which is how I'm sending keystrokes to the FPGA).
The real stumper though was seems to be an apparent bug in the T65 6502 core I got from open cores. It seems that during a PLP instruction the disable interrupt flag randomly got changed to off (i.e. interrupts enabled) even when the P register had it set before the PLP and the value on the stack had it set.
I made a small change to the core to ignore the IRQ_n_o while LDP (load P from ALU signal) is high,during which time it is unstable.
... t65.vhd line 542 on
-- DOM HACK : PLP causes Flag_I to follow ALU_Q during LDP, ignore until
-- LDP is low, otherwise get spurious irq cycles during PLP even if
-- I is set before and after PLP!
elsif IRQ_n_o = '0' and P(Flag_I) = '0' and LDP = '0' then
IRQCycle <= '1';
end if;
There were a few problems of my own that I had to overcome...such as spotting some address selection logic that I'd commented out for some unknown reason and some dodginess with my SPI slave implementation (which is how I'm sending keystrokes to the FPGA).
The real stumper though was seems to be an apparent bug in the T65 6502 core I got from open cores. It seems that during a PLP instruction the disable interrupt flag randomly got changed to off (i.e. interrupts enabled) even when the P register had it set before the PLP and the value on the stack had it set.
I made a small change to the core to ignore the IRQ_n_o while LDP (load P from ALU signal) is high,during which time it is unstable.
... t65.vhd line 542 on
-- DOM HACK : PLP causes Flag_I to follow ALU_Q during LDP, ignore until
-- LDP is low, otherwise get spurious irq cycles during PLP even if
-- I is set before and after PLP!
elsif IRQ_n_o = '0' and P(Flag_I) = '0' and LDP = '0' then
IRQCycle <= '1';
end if;
Seems to work ok but I'm not clear why nobody else has run into this one or is it some timing thing I'm doing?
Sunday 23 March 2014
Carb rebuilt
Finished off rebuilding the Carburetor today and fitted to the intake manifold. Took a bit of faffing to get the float level right...until I realised that I'd left out the thick spacer washer on the needle valve assembly.
Hopefully it will all work when I try it but that is going to be a while away yet. I'd hoped that I'd be driving to Le Mans in it last year, at this rate it might be ready for June 2015...
Hopefully it will all work when I try it but that is going to be a while away yet. I'd hoped that I'd be driving to Le Mans in it last year, at this rate it might be ready for June 2015...
Tuesday 11 March 2014
Brrrrrr--beep!
Ok, so it doesn't really make a noise but after having hacked the MOS rom and fixed some address decoding issues I can now boot to a BASIC / BBC Micro Mode 0 prompt. No keyboard yet so I can't talk to it.
Sunday 9 March 2014
hdmi+6502
I've now got a functioning 6502 system hooked together with a hdmi graphics card - all running on the FPGA.
This has 32k RAM, 32k ROM, an LCD display, an HDMI display (like a BBC mode 0 640x256x1bpp bitmapped in8x80x32. Uses the r6502_tc core running at 25MHz (could go faster) and a little test ROM I hacked up to give it some exercise.
Next up will be either to hack together a MOS rom and BBC basic and a keyboard adaptor (maybe via the Raspberry pi for now) or alternatively I might take an existing BBC micro system and graft on HDMI...not sure yet...I just like writing 6502 code...
This has 32k RAM, 32k ROM, an LCD display, an HDMI display (like a BBC mode 0 640x256x1bpp bitmapped in8x80x32. Uses the r6502_tc core running at 25MHz (could go faster) and a little test ROM I hacked up to give it some exercise.
Next up will be either to hack together a MOS rom and BBC basic and a keyboard adaptor (maybe via the Raspberry pi for now) or alternatively I might take an existing BBC micro system and graft on HDMI...not sure yet...I just like writing 6502 code...
Monday 3 March 2014
My first graphics card....well my second
A bit more poking around this evening has now got it accessing on-chip RAM. It's pretty simple (and ropey) but it works. Shown is a screen dump from a BBC Micro loaded into memory as a .HEX file and a bit of colour at the bottom. Next up, I'll be going through some of the BBC Micro implementations on the net and pick out my favourite (looking like Mike Stirling's at present) to hack together a full BBC / HDMI on a DE0.
One thing I've discovered in the past few days is that most computer monitors (as opposed to TV's) won't support the normal SD modes i.e. 576i, which is what I was hoping for, as that would allow me to use the original 6845 timings to drive the DVI/HDMI. Looks like that's out though as my monitor requires a line rate of at least 30kHz and a frame rate of over 50Hz. The first obstacle can be avoided by buffering a line of video output at 15625Hz and outputting it twice. The second is a bit more tricky. I'm either going to have to buffer the entire frame and output at 60Hz (yuck - this will lead to gittery looking games) or maybe just cheat by running the BBC's master clock at 33Mhz instead of 32!
This is now my second attempt at a graphics card. The first one was a real hardware project, not just fpga but was a little less powerful at 32x48 pixels!
One thing I've discovered in the past few days is that most computer monitors (as opposed to TV's) won't support the normal SD modes i.e. 576i, which is what I was hoping for, as that would allow me to use the original 6845 timings to drive the DVI/HDMI. Looks like that's out though as my monitor requires a line rate of at least 30kHz and a frame rate of over 50Hz. The first obstacle can be avoided by buffering a line of video output at 15625Hz and outputting it twice. The second is a bit more tricky. I'm either going to have to buffer the entire frame and output at 60Hz (yuck - this will lead to gittery looking games) or maybe just cheat by running the BBC's master clock at 33Mhz instead of 32!
This is now my second attempt at a graphics card. The first one was a real hardware project, not just fpga but was a little less powerful at 32x48 pixels!
Subscribe to:
Posts (Atom)