Some Sprite Bug Fixes

Deft from MEGA did some testing on the MEGA65 recently and pinned down a pesky sprite colour bug that had been causing problems. Basically some sprites were appearing in a single solid colour that was not the right colour.  He worked out that all high-resolution, i.e., non-multi-colour, sprites were appearing in the sprite multi-colour colour 1, instead of the right colour.  You can see what goes wrong here:

With this very precise information I was able to make a quick patch to the VHDL code to fix the bug, resynthesise it, and send Deft the bitstream, which he confirmed on his board fixes the problem. So now it looks like:

At the same time I also made $D055 select whether to make sprites the normal 21 pixels high, or allow them to be a variable height (set via $D056), but this hasn't been tested yet.

Planning which ports we can support

I don't have much time at the moment to work on the MEGA65, but we have been able to do some planning on which ports we expect to support.

The following is what we have made electrical provision for.  Note that this is different from what may be on the actual main boards, due to space and/or cost issues, but it is the set of ports that we should be able to support, all with real 5V signals.

1. Stereo SID sockets
2. Stereo RCA audio output
3. VGA video output
4. 100mbit ethernet
5. 34-pin floppy drive interface (720k, 1.44MB and hopefully 2.88MB floppy drives, as well as 5.25" PC floppy drives although we aren't putting special effort into this).
6. C64 and C65 keyboard
7. joysticks (with full paddle support)
8. Expansion/cartridge port (initially only relatively simple ROM cartridges, but we have all signals plumbed, including DMA)
9. IEC serial for 1541 and other Commodore floppy drives
10. Extra SD card socket (in addition to the microSD socket on the FPGA board)
11. Cassette port
12. MIDI interface
13. Composite video (although it will initially be 100% compatible with the C65's composite video port -- i.e., it won't work ;) -- we are just making provision for implementing it later on.
14. DVI/HDMI video (this also won't work initially)

The main omissions compared to a real C64 or C65 is the user port, which shouldn't be any need with all the IO options on the MEGA65.

When I have more time I'll explain how we are connecting all this stuff using just 40 I/O lines on the FPGA.  Perhaps after we have had a chance to see if our way of implementing it actually works ;)

Teaching the young to program

One of my goals in creating the MEGA65/C65GS is to create a computer platform that is easy enough to understand that it can be used to teach new generations the fundamentals of computing in the same way that 8-bit computers taught previous generations.

Thus it was both amusing and somewhat distressing to hear about the recent comments by our prime minister who ridiculed the need to teaching the young to code, before back-pedalling when he realised that his own party is making an effort to do just this, although that effort is rather poultry.

http://www.smh.com.au/national/education/tony-abbott-ridicules-his-own-party-in-school-coding-gaffe-20150528-ghbdal.html

Nexys4 DDR Boards are out of stock everywhere it seems

So, it seems that there are no Nexys4DDR boards in stock in the USA, UK or continental Europe.

We probably aren't the major cause of this, but it would be funny to find if we were.

For those desperate in the meantime, it might be possible to get them from the Australian distributor, although where I am at the moment it isn't trivial for me to find out their stock levels.  Perhaps someone can leave a comment with what they find out.

Otherwise, Digilent seem to have another production run scheduled for later this month, with stock shipping again from the 29th.

Wir sind in den Nachrichten

That is, we are in the news, in German, in Germany.

Two fairly well known IT/computing magazines there have run stories on the MEGA65 / C65GS in the last couple of days:

http://www.heise.de/newsticker/meldung/Retro-Computing-Nachfolger-des-C64-soll-als-MEGA65-erscheinen-2621439.html

and

http://www.pcwelt.de/news/Mega65-soll-Nachfolger-des-C64-werden-Commodores-vergessener-C65-9650404.html

I have been trying to respond to comments on the Heise.DE article, which has been stretching my limited German, but this is a good thing, because I am trying to improve my German :)

I'll try to summarise some of the recurring questions there and elsewhere here, for your convenience:

What will the case look like?

We are trying to make the case look as much like the original C65 prototypes as we can.

Will it have a real 3.5" floppy drive?

We hope so! We are certainly intending that this will be the case.

Do we have to choose between SD Card support and having a real floppy drive?

No, if we add floppy drive support, it will do both at the same time.  Probably how this will work in practice is that the hypervisor will read sectors from the floppy drive, and put them on the SD card, from where they will be read using our C65 F011 floppy drive controller compatible SD card controller.  Writing sectors to disk will do something similar in reverse, again using the hypervisor to trap the disk accesses.

Isn't all this going to cost a lot of money (just think of the injection moulds alone)?

Yes, it will.  This is why we are asking for donations on mega65.org.  Also, if you happen to have the skills and facilities to make injection moulding tools, and would like to volunteer to help us, we would love to hear from you, and probably even put your name on the inside of every case.

Isn't this whole project rather pointless?

This is a rather common question on forums and in comments to these articles.

The answer, of course, is that it rather insane. That's the point.  So now we can all move on happily: they can be right, and we will just keep making it anyway ;)

However, while it is rather pointless, it isn't completely pointless. It's like the difference between mostly dead and completely dead in The Princess Bride.  The MEGA65 will be fun for those for whom it is fun, which is one purpose.  Also, I intend to build and use a set of MEGA65 computers in teaching University and high-school students about "hardware intimate programming", to hopefully improve their understanding of computers and improve their future career prospects and enjoyment.

Introducing the MEGA65 Retro Computer

Hello all,

For a few months now I have been working behind the scenes with the good folks at m-e-g-a.org, exploring our mutual desire to create a physical 8-bit computer in the spirit of the C65, but that is open-source and open-hardware so far as is possible, so that the community can sustain, improve and explore it.

Basically, we agreed that we wanted to do this, and that the C65GS was the logical basis for this, and thus the MEGA65 project was born, to take the C65GS core, to work together to improve it, and plan towards creating a physical form that is strongly reminiscent of the C65 prototypes.

Our initial announcement is online at http://www.m-e-g-a.org/mega65-introduction/.

This is also the point at which we are ready to offer pre-prepared FPGA bitstreams.

These bitstreams are still experimental, and updated bitstreams may break things that were working in previous bitstreams as we progressively spiral in on the final product.  This process might take another year or two depending on what support we can raise, being done voluntarily in our discretionary time as it is.

What we have decided to do to help support the project is to ask for a donation of your choosing to be given access to our FPGA bitstream build server that will contain the latest bitstreams.  Our desire is not to exclude anyone -- which is why we are not dictating a donation that is in any way representative of the costs of undertaking this project.  Also, everyone will still be free to compile the bitstreams themselves, but we hope that you will appreciate both the convenience and opportunity to support the project.

Finally, we now have a Twitter account (@Mega65Retro), and Facebook page (https://www.facebook.com/MEGA65RetroComputer) -- so feel free to spread the word.

Generalised disk access routines now work

After a fair bit of refactoring and debugging, I have the new generalised disk access code working,It still has a few wrinkles (like file names longer than 14 letters get chopped off at 14 letters), and the C65GS can now boot up completely using the new code.

To give an idea of the interface now, here is the code that loads the C65 ROM into place:

loadc65rom:
ldx #<txt_c65gsrom
ldy #>txt_c65gsrom
jsr dos_setname

; Prepare pointer for load address ($0020000)
lda #$00
sta <dos_file_loadaddress+0
sta <dos_file_loadaddress+1
sta <dos_file_loadaddress+3
lda #$02
sta <dos_file_loadaddress+2

jsr dos_readfileintomemory
bcs loadedok

As you can see, for the simplest use-cases, it is pretty simple: just set the name of the file you want to load, provide the load address, and then use the dos_readfileintomemory utility function that looks after everthing else.  We are using the convention of setting the carry flag if a function completes successfully, or clear otherwise.  In the case of an error, dos_error_code contains the reason fore failure. I have tried to provide meaningful error codes for all things that can go wrong at the moment.

Drilling down a little, we can see how the dos_readfileintomemory function works.  There are few little complexities in that function that I will explain:

dos_readfileintomemory:
; file name must be already loaded into
        ; dos_requested_filename,
; with length in dos_requested_filename_length

We keep track of the number of sectors read, so that we don't get stuck forever if we hit a file with a tangled cluster chain.
; Clear number of sectors read
ldx #$00
stx dos_sectorsread
stx dos_sectorsread+1

Next, we need to find the file and get its details in the single directory entry structure (dos_dirent). A call to dos_findfirst leaves the file descriptor for the directory search open, in case you want to call dos_findnext to find more matching files. So we need to take care to close the file descriptor so that we don't run out.  This is really important, because the hypervisor supplies a grand total of only four file descriptors.  We can't trust dos_closefile to not mess with the carry flag, so we save the processor flags on the stack before closing the file descriptor, and then propagate any error up by jumping to dos_return_error_already_set, which preserves the value in dos_error_code.

jsr dos_findfirst
php
; close directory now that we have what we were
        ; looking for so that we don't leak file descriptors ...
jsr dos_closefile
plp
; ... but report if we hit an error
bcc dos_return_error_already_set

jsr dos_openfile
bcc dos_return_error_already_set

Next we need to make the SD card sector buffer visible at $DE00-$DFFF.  In future, this and the following code will need to be generalised a bit to allow disks on other media, in which case we will need to instead have a pointer to the sector buffer.  But for now we have a structure that works, and has the flexibility to add such functionality later without breaking compatibility.
        ; Make sector buffer visible at $DE00-$DFFF
jsr sd_map_sectorbuffer

Now we enter the main loop where we read the data into memory.  We read the current sector, then copy the 512 bytes into place, update the pointer, and ask for the next sector, if there is one.  For now, we just use a simple copy loop using the 32-bit pointer access.  It would be quite a bit faster if we used DMA to transfer the sector buffer. It might even take a few less bytes, especially if we embed the load address pointer directly into the DMA list.

drfim_sector_loop:
jsr dos_file_read_current_sector
bcc drfim_eof

; copy sector to memory
ldx #$00
ldz #$00
drfim_rr1:
lda $de00,x
nop ; 32-bit pointer access follows
sta (<dos_file_loadaddress),z
inz
inx
bne drfim_rr1
inw <dos_file_loadaddress+1
drfim_rr1b:
lda $df00,x
nop ; 32-bit pointer access follows
sta (<dos_file_loadaddress),z
inz
inx
bne drfim_rr1b

jsr dos_file_advance_to_next_sector
bcc drfim_eof

Here we have a little security feature: You cannot load across a 16MB memory boundary. This is designed to prevent calls from user-space inadvertently or maliciously trying to load code that will end up loading over the top of the hypervisor.  The 16MB boundary is enforced simply by refusing to increment the upper byte of the load address when we update the memory pointer used to write the data into memory. It isn't actually sufficient yet to be completely effective in this function, because any load to the IO memory space, which includes the hypervisor, could potentially overwrite the hypervisor, but I am already thinking about how to make these calls secure, so that, (a) the machine doesn't crash easily, and (b) so that it actually has good security.  

; We only allow loading into a 16MB space
; Provided that we check the load address before starting,
; this ensures that a user-land request cannot load a huge file
; that eventually overwrites the hypervisor and results in privilege
; escalation.
inw <dos_file_loadaddress+1

; Increment number of sectors read (16 bit valie)
inc dos_sectorsread
bne drfim_sector_loop
inc dos_sectorsread+1
; see if there is another sector
bne drfim_sector_loop

This point in the code is reached if we have read 64K sectors = 64K x 512 bytes = 32MB.  Note that we supply a meaninful error code so that the caller knows what has happened.
jsr dos_closefile

; File is >65535 sectors (32MB), report error
lda #dos_errorcode_file_too_long
jmp dos_return_error

Finally, when we reach the end of file, we need to close the file to protect our precious few file descriptors, and indicate success to the caller.
drfim_eof:
jsr dos_closefile
jmp dos_return_success

You can also hopefully see in the above that there are functions for various other operations that are necessary.  So I now have all the basic building pieces to make a few useful disk access functions available to user-land, which I will look to do soon, so that hopefully in the near future you will be able to load a file of up to a few mega-bytes quickly and easily with just a few lines of assembly code.