gardners / c65gs Goto Github PK
View Code? Open in Web Editor NEWFPGA-based C64 Accelerator / C65 like computer
FPGA-based C64 Accelerator / C65 like computer
For example, while booting the C65 ROM, an IRQ is triggered at $BA1D in the DOS initialisation, despite the fact that all interrupts are masked due to the use of MAP.
Issue #27 depends on this being fixed.
Last byte of sector ends up in first byte of buffer, and all else seems to be pushed forward one location. This is preventing loading of ROM from SD card (Issue #27).
... and pressing it again does something else odd.
Need to fetch the data for the correct row of the sprites, and then add sprite drawing to the pixel pipeline. Three bytes of a sprite row can be fetched in at most two cycles, plus one extra fetch for all eight sprites to get their location in the 16KB addressable bank.
Fetching of all sprites should begin as soon as the right border is activated, to allow as many cycles as possible for fetching not just the VIC-II sprites, but also the new 256-colour VIC-IV sprites.
Fairly self explanatory. Need to add C65 interface ROM @ $C000 and DOS ROM as the minimum to boot into C64 mode. Need to consider mapping the C65 ROMs to $0020000 - $003FFFF to make it easier to implement MAP instruction.
glyph_pixeldata is shifted in the last cycle of a char, which takes precedence over the writing in of the new pixel data.
Colour and glyph number is only updated every 3 or 2 characters.
Required for Issue #27, as interface routine at $CAF4 waits for serial port to empty/fill?
The Nexys4 has an ethernet adapter based on the LAN8720A which it would be good to support. Requires a 50MHz clock. There are some proprietary cores for driving it, but many seem to need a prescribed processor core to go with it, whereas we want a direct mapped IO, and preferably LGPL license.
As described above. Requires SD card controller working adequately.
Quite likely a bug introduced when fixing the issue #10. Should just require updating of $D016 horizontal placement equations.
In C64 mode the following code:
POKE53280,0:POKE53281,1:POKE646,0:POKE199,1:FOR T=1 TO 800:?" ";:NEXT T
shows a thin white line on the right side just before the border
starts but after the screen content ends. It looks as if the content
of the screen is displayed half a dot-cycle too early...
It seems that this also affect the C65-mode. If you run the following
basic code in C65-mode just after booting up the machine:
FORT=1TO1000:?"R ";:NEXTT (The R in the print string is CTRL-9
(Revers mode on))
you can see (beside other wired horizontal lines that are appearing on
screen) that the white screen content does not align with the yellow
border on the right side. You can see a small blue line of the
background color. In addition I think it overlaps half a dot-cycle on
the left side.
Most of the machinery is in place, but it doesn't actually work.
Consider simulation to see what is going on with the fetching and display.
Make notes here about what happens when bitplane mode is enabled.
First byte does rightmost of 8 pixels.
BRK, RTI and interrupts must all use the same semantics for the machine to run.
They do, but the pushed address is too high by one.
The following list at $03E6 on the C65 should fill the colour RAM for a screen line at $1FAD0 - $1FB1F with $01, but it instead gets filled with $E6:
03 50 00 01 F0 01 D0 FA 01 00
As a result, the C65 screen is filled black (palette value $06 + bold (i.e., palette + $20) + reversed) instead of background colour with white text.
Spotted a bug in machine.vhdl where the CPU clock was incorrectly divided from the pixelclock, resulting in CPU clock being 1/2 the expected speed.
Also changing CPU speed should not affect UART baud rate, as that link is unnecessary and rather annoying.
Reported by a user:
Second topic: C64 sprites (just basic sprites, but more difficult to
demonstrate)
Please enter the following code in C64 mode:
POKE53280,6:POKE53281,0
POKE53248,23:POKE53249,55:POKE2040,64:POKE53287,1:POKE53269,1
FOR T=4096 TO 4159:POKE T,0:NEXT
POKE4096,128:POKE4098,1:POKE4099,128:POKE4101,1
POKE4102,192:POKE4104,3:POKE4105,192:POKE4107,3
POKE4108,224:POKE4110,7:POKE4111,224:POKE4113,7
Here you can see that the sprites is being displayed not only on
screen but also in front of the border. Maybe this can be seen more
clearly if the screen color is white and the border color is black:
POKE53280,0:POKE53281,1
Now the left transition from black border to white screen is not as
straight as it should be. One can see the sprite clearly reaching into
the border.
e.g., so that TXS, TYS cannot be split by an interrupt. Not currently implemented.
For our design, this will in practice mean no interrupts after single byte instructions.
If we put the CPU-side interface of the fastram onto the pixel clock, instead of the cpuclock, reads will occur in less than one CPU cycle, so the waitstate can be removed. The question is whether it will introduce any write glitches, which obviously we cannot tolerate.
Trying SDHC mode on SD cards adds ~2 seconds to the kickstart time, instead of SD card access being possible within ~0.2 seconds. This is very annoying. SD mode is okay for SDHC cards when accessing the first 2GB as far as I know. So we should just bring the card up in SD mode, and when first trying to access a sector >2GB, then we should try for SDHC mode, and incur the delay only at that point in time.
line 188
fastio_rdata(6) <= reg_status6_tx_empty;
is reported as critical warning, multi driven net in vivado, fixed CONSTANT is selected, so it would cause error in function
Suspect $D016 compatibility problems.
The branch stress tests use BRK to determine where the branch has landed. BRK currently pushes the PC after incremented rather than before, resulting in it being out by one. These stress tests misinterpret that as the branch instruction branching to the wrong address.
See Issue #1 for the complications in fixing this issue at its cause.
The stereo microphone is likely very easy to add support for. We can just map the left and right samples to a couple of registers.
The ADMP421 outputs in Pulse Density Modulation (PDM), which would need conversion to 8-bit samples.
The first stage is to simply clock the unit at 1MHz - 5MHz. Higher frequencies are probably preferable for improving audio quality.
Then pull the audio bits out for left and right channels alternately.
Finally, the samples need to be integrated from the pulse stream. We need to find a suitable algorithm for this. It might be as simple as counting the 1s in the most recent x pulses.
See https://svn.pacedev.net/repos/pace/sw/src/component/sound/sid/ and http://papilio.cc/index.php?n=Playground.C64SID for options for existing FPGA SIDs. Filters are external apparently.
Should be none, just the character data we want.
This of course depends on issue #43.
A link to the D81 file for testing would be helpful here...
If I am not wrong, the SD interface logic assume an internal buffer size of 512 byte. However, the SD card specification > 1.x extend possible block sizes from 512 up to 2048 bytes. As there exist known access problems for some SD card controllers assuming lower block lengths as initially registered, future, card-producer specific compatibility problems are likely.
There exist multiple dependencies which limit a fast work around:
Suggestion:
In most cases this possible compatibility problem is avoidable by initially limit the registered block size to 512 byte for read and write operations (Transfer Block Size register = 0200h). This should be done somehow at controller reset (sd_reset). However, it's a hack which does not work in few cases.
Memory mapper makes this a bit interesting to do.
Current thoughts:
Currently CPU is about 1/2 the speed of a similarly clocked 6502, largely due to a single wait state on reading from chipram. This is incurred for each read, even if multiple reads are required in an instruction, and the reads could therefore be pipelined.
Implement a ZP cache for odd and even ZP addresses that can be used to resolve ZP indirect addresses in a single cycle.
chargen activation is triggered off displayx, not xcounter, which means the 20 cycle lead time is not available.
chargen activation should all be based on xcounter values instead.
The SD card controller should have the facility to pretend to be the F011 FDC controller. This will require mapping logical 1581 sector numbers to physical SD card sectors.
On the upside, the F011 has an 8-bit register for side, which removes one barrier to supporting DHD images in future.
Depends on Issue #24.
(but seems fine at scale_x>1)
Reading, e.g, $DC01 when DDR=in only works for bits where the output register are zero. This affects keyboard and joystick input.
For example:
LDA #$00
STA $DC03
LDA #$FF
STA $DC01
LDA $DC01 ; Will always return $FF, regardless of the state of the input bits of the port
To make this bug more annoying, it works in simulation in tb_cia.vhdl, but not on the synthesised design.
Palette needs to be reimplemented as dual-port block ram so that fastio side can write to it. Also consider making palette 1024 entries, with some bits to select the palette to use. Also consider allowing sprites to pull from a different such "palette bank" to the character/bitmap display.
Self explanatory.
Candidate sd card controller at https://github.com/xesscorp/XuLA2/blob/master/FPGA/XuLA_lib/SDCard.vhd
That is licensed under GPL, which may pose problems for synthesising with xilinx coregen modules. Need to see how xesscorp deal with that.
On the sdcard4 branch atleast, the following instructions will not execute reliably:
loop: ldz $D680
INC $D020
JMP loop
Inserting 3 NOPs after the LDZ helps, but is not a sure cure.
Basically it looks like there is some problem with the fastio system, perhaps with read values having latches inferred when they shouldn't.
Implement cellular RAM as 16MB slow RAM.
Consider making read & write wait states configurable to allow pushing of bounds?
Doesn't seem to change the memory mapping.
in viciv.hdl
unsigned(r_blnd) => antialiased_red,
unsigned(g_blnd) => antialiased_green,
unsigned(b_blnd) => antialiased_blue
reported as bad VHDL syntax by Vviado synthesis
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.