gardners / c65gs

FPGA-based C64 Accelerator / C65 like computer

All active work on the MEGA65 / C65GS project has moved to https://github.com/mega65/mega65-core

c65gs's Issues

Artifact in text mode

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.

Character generator starts drawing characters a few pixels late

Executing from FastIO ROM has problems

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.

Two columns of junk characters on left edge of character display

Should be none, just the character data we want.

Fullcolour characters don't work at physical x resolution

glyph_pixeldata is shifted in the last cycle of a char, which takes precedence over the writing in of the new pixel data.

CPU lacks 4510 instructions for C65 compatibility

sd card interface logic and kickstart routines presupposes a block size of 512 byte

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:

• 1. The SD interface logic is block size dependent (sdcardio.vhdl, lines 1181..1192)
• The FDC emulation logic also assumes a natural block size of 512 byte (= logic block size)
• Relevant kickstart routines depend on a buffer size of 512 byte (kickstart.a65, lines 1181-1192)
• There exist no independent abstraction between kickstart, SD interface logic and controller interface

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.

c54uart multi-driven net

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

4502 interrupts should not occur after one cycle instructions

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.

SETMAP CPU instruction (opcode $02) doesn't seem to work

Doesn't seem to change the memory mapping.

CPU IPC is low: implement i-cache

Memory mapper makes this a bit interesting to do.

Current thoughts:

• 1K 4-way associative cache with random replacement.
• Need random(ish) bit sequence generator.
• The cache would hold 3 bytes of fetched instruction.
• Cache lookup would occur when setting state <= InstructionFetch, so that it would be possible to execute an instruction every cycle.
• Cache address would be 28-bit address minus lowest 10-bits mapped by cache location.
• When writing to a byte, we need to potentially invalidate three cache lines, as the byte could occur in one of three addresses.
• Simplest approach for invalidation is to clear cache valid flag for all three affected cache lines, including all four sets in the cache line. To do otherwise would require loading the cache lines to check which needs invalidation. This should not affect performance much, anyway.
• Structure cache as 4 256 x 4-way sub-caches, based on address bits (9 downto 2). That way the invalidation-on-write can happen in parallel to the three lines that need it.

CPU IPC is very low. Implement ZP cache to speed up ZP addressing modes

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.

CPU speed and UART speed are tied. CPU speed is 1/2 claimed rate

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.

First column of text shifted right one pixel when scale_x=0 or 1

(but seems fine at scale_x>1)

Ethernet adapter not supported

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.

Need a kickstart ROM to load C65 ROM from microSD card and run it.

As described above. Requires SD card controller working adequately.

DMAgic fill is filling with the low-order address of the list instead of the fill value

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.

VIC-II Sprites are not implemented.

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.

ghdl_farstack not recoginized as RAM with vivado synthesis

unsigned(r_blnd) => antialiased_red,

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

CIAs lack serial port

Required for Issue #27, as interface routine at $CAF4 waits for serial port to empty/fill?

Stereo microphone is not supported

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.

Sprites can still appear in front of the border

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.

Design lacks SID chip(s)

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.

palette registers not writeable

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.

CPU IPC is low: eradicate fastram wait-state on read

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.

Need C65 ROMs to be able to boot from C65 C64-mode kernel

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.

Screen still in 39 column mode after C64 starts up.

Suspect $D016 compatibility problems.

SD card controller should provide F011 emulation registers at $D080

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.

Fullcolour characters have pixel order reversed.

First byte does rightmost of 8 pixels.

C65 / VIC-III bitplanes don't work

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.

chargen cannot start at pixel column 0

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.

Character generator misbehaves if X scaling is <3x ($D042=$00 or $D042=$01)

Colour and glyph number is only updated every 3 or 2 characters.

16MB Slow RAM not implemented

Implement cellular RAM as 16MB slow RAM.

Consider making read & write wait states configurable to allow pushing of bounds?

SD card reads sector into buffer rotated by one byte

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).

control-n for lower case also changes screen ram address

... and pressing it again does something else odd.

Need DMAgic implemented to boot C65 ROM

This is a sub-issue of Issue #27.

Some initial work exists in commit db76544.

IRQs are being triggered at odd times when they are fully masked

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.

No microSD card support

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.

CIA ports cannot be read properly

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.

VIC-IV does not generate interrupts

First raster of text display is all blank; chops top pixel off first row of text.

Address pushed by BRK (and presumably interrupts) onto stack is too high by 1

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.

character field is about 15 pixels left of where it should be after writing to $D016

Quite likely a bug introduced when fixing the issue #10. Should just require updating of $D016 horizontal placement equations.

BEQR, BNER and other branch instruction stress tests fail due to BRK bug (Issue #1)

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.

C65 BASIC Graphics demos don't work

This of course depends on issue #43.

A link to the D81 file for testing would be helpful here...

Kickstart should try SDHC mode only when first reading a sector >2G

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.