GithubHelp home page GithubHelp logo

gardners / c65gs Goto Github PK

View Code? Open in Web Editor NEW
83.0 25.0 23.0 12.14 MB

FPGA-based C64 Accelerator / C65 like computer

C 2.68% VHDL 39.70% Python 0.08% Java 0.06% Tcl 0.97% Shell 0.02% Stata 0.17% Makefile 0.18% Batchfile 0.76% Verilog 55.38%

c65gs's Introduction

c65gs's People

Contributors

blaizer avatar gardners avatar justburn avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

16MB Slow RAM not implemented

Implement cellular RAM as 16MB slow RAM.

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

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.

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.