OpenROMs Update

Howdy folks,

Feral Child has been working through the European summer heat on the OpenROMs (our free and open-source C64/C65 ROM project), and has the following update for our reading and viewing pleasure:

---

Hi there! It's been a while since the previous Open ROMs update, time for a new one!

I'll start from not-so-good news - I'm running out of ROM space. On the stock C64 the Kernal + BASIC has to fit within 16 KB total; with the original C64 ROM set there are very few bytes left, and the code is already space-optimized most of the time. That means, if you reimplement the firmware (or mod the original one), it is very hard (or even impossible) to add any significant feature without removing something else. This is already clearly visible - for unexpanded ROM it is no longer possible to enable all the features the Kernal replacement offers, also there is not that much BASIC ROM area left. For example, I had to disable the built-in tape head alignment tool for the default build:

https://vimeo.com/425935795

Fortunately, lack of space is not a problem on the MEGA65 - it has an abundance of extra ROM, which can be mapped anywhere in the C64 address space with 8KB granularity. Also, the Ultimate64 community started an interesting effort - additional Kernal ROM banks. Although the concept is quite different from what MEGA65 does, it should still be possible to take advantage of this extra space in the future.

So, what takes so much space? The official Kernal API is nearly complete at this moment, but feature-wise... it is now able to utilize two most popular drive mods: DolphinDOS and JiffyDOS (but the latter protocol is not fully implemented yet, LOADing is not as fast as it could be - but still much faster than with standard IEC transfer). Additionally, there is tape support - limited to loading programs, but can read both the standard format and TurboTape64. The turbo-saved files can be up to 250 blocks long (not all the implementations can read such a large chunks of data), and there are raster and sound effects (with normal format only raster effects are available - it uses such a long pulses, that for now every attempt to add SFX resulted in a very low buzzing sound, probably dangerous to the speakers in the long run). And that's not all - normal/turbo formats can be autodetected, you don't have to worry about special syntax to select the proper loading routine. No turbo implementation I know is able to do this!

BASIC also saw some work, although it still needs more effort before it is really usable. Besides various reworks and speed improvements, at last we have some variable support. For now only strings (including TI$, string arrays are mostly functional too!) - although some floating point routines are already written, they still need more testing, and are not exposed as variables yet. The expression parser (code that interprets mathematical expressions, including brackets and operator precedence) is already written too - for now it can be used to concatenate strings.

Our string handling is a little bit different than C64 one. Microsoft BASIC interpreter has a mechanism called garbage collector, which is triggered once there is so much garbage (obsolete strings - replaced with different ones, but still kept in memory), that it isn't possible to allocate any more memory - the original mechanism (used in PETs, VIC-20, and C64) is very ineffective (square computational complexity), the C64 can freeze for half a minute before the process is complete. Starting from CBM-II and C16/C116/C+4, an improved algorithm was implemented - much faster, but requires additional 2 bytes per each string, a so-called back-pointer. Open ROMs contains a similar mechanism, although it differs in details (there is no magic value to denote a temporary string). You can read more about these algorithms here:

https://www.c64-wiki.com/wiki/Garbage_Collection

Open ROMs has one more improvement over the original memory handling - the Commodore C64 ROM displays '38911 BASIC BYTES FREE' message on the startup banner, despite the machine having 64KB of RAM (not including the colour memory). 38911 is much less than 64KB - but this was done for a reason. First, the ROM needs some memory for itself, to store screen content and some other stuff - this takes away 2KB. Second, some of the RAM cannot be easily accessed by C64 BASIC, as it is hidden 'below' the ROM or I/O area. Old builds of Open ROMs displayed '61438 BASIC BYTES FREE', as they contained a specialized code (helper routines, which has to be copied to RAM) to access nearly all the C64 memory. But this code has two drawbacks: it is much slower, and utilizes some RAM which normally can be used by applications or games - which might easily lead to compatibility problems. Therefore, at some point I have disabled this mechanism (but it is still there, and can be enabled on custom builds) and implemented the C64-like behaviour. But now the default Open ROMs build displays '51199 BYTES FREE':

because we have another 'memory model', which is able to use RAM hidden below the $A000-$BFFF BASIC ROM - which can be accessed relatively cheaply if the memory access routines are placed in a high ROM area, $E000 or above. It does not use RAM below the I/O or the $E000-$FFFF ROM - it is harder to access safely, as one has to redirect the interrupt handlers back to the ROM. I hope this will remain as a default memory model for MEGA65 build - I'm not sure about the generic C64 one, as the required memory access routines need some extra ROM space.

That's all for now - let's hope not much will be found broken once I start testing the Open ROMs with the upcoming DevKit!

Debugging IEC port on MEGA65 R2/R3 boards

So we are almost finished testing the MEGA65 R3 board, but have hit a funny problem, that is now also showing up on my R2 board:  The IEC port is not working reliably.

The symptom is that the CLK and DATA  lines don't go to 0V when they are pulled low by the MEGA65, but stay at around 2V -- but only when a drive is connected.  

The only "drive" I have here in the desert with me is a Pi1541, so that will have to do.  Fortunately it has nice test points:

 

It uses a 7406 inverting hex buffer, to give maximum compatibility.

The Pi1541 uses 1K pull-ups, resulting in 5mA at 5V, while the MEGA65 uses NC7SZ126 drivers, which can sink 25mA. So the MEGA65 really should win, hands down.  But this is not what we see.

What is interesting, is that the problem occurs, even if the Pi1541 is not powered.  After being reminded that 7406's can be fried by hot-plugging drives and computers while powered on, I am now wondering if it isn't the 7406 that is fried.  Because the MEGA65's drivers are quite strong, I wonder if that hasn't increased the likelihood.

Basically I can't think of a better theory, since the problem happens only when the Pi1541 hat is connected to the MEGA65, even if I disconnect the hat from the Pi itself.  There just isn't really much more on the board apart from that and the pull-ups.  I did test that the pull-ups weren't too heavy by measuring the resistance between the lines, and also simulating 1K pull-up with a resistor directly in the MEGA65's IEC port.

So time to pull and replace the 7406. There are a few problems, though. First, I'm in the middle of the Outback with only limited facilities. I *thought* I had packed a set of hot soldering tweesers as part my soldering station, but that was, sadly, only my imagination speaking.  So that means its time for some quality time with my solder sucker. Except that seems to make as good a seal as a fly-screen door on a submarine.  So time to chop the legs of the 7406, and poke them out with the soldering iron one by one and replace the chip.  

Now about replacing that chip... I still live in the middle of the Outback.  Fortunately I do have my box of crazy electronics parts, which includes a good selection of early 1980s 74 glue chips. Unfortunately, none are 7406's.  BUT I have several 7405s, which are quite similar, but have lower maximum current sink capacity.  Depending on the manufacture it can be a limit of around 8mA instead of 30 or 40mA for the 7606.  8mA is probably sailing a bit close to the wind, but as the nearest spare 7406 is several hundred kilometres away, we'll give it a try. The worst that can happen is that we let the magic smoke out.

But while I am working through all of that, it occurred to me that the original problem of the IEC port not working properly might have been that I was controlling the IEC drivers on the MEGA65 main board incorrectly, pushing high, instead of tri-stating the output buffer, and relying on the pull-up resistors to float the lines high.  

Of course I realised this just after the German part of the team had gone to sleep for the night, and as I don't have any other drives here, I couldn't test it.  Anton has now tested it on his R2 and R3 PCBs, and his SD2IEC and 1581 each work on both boards.  However, his 1541 didn't work on the R3. Testing it on the R2 board found it also not working there. So now we are trying to work out if his 1541 is faulty, or if the MEGA65s are having problems communicating with real 1541s.

We know the problem is unlikely to be timing, because the other drives work.  

So we are now remotely going through the process of probing the IEC lines with his 1581 plugged in, which we know works.  We will then repeat the process with the 1541 plugged in, and see if we can spot any differences. As this can be sensitive to the level of the IEC signals, we will do it 8 times on each, with the different IEC line level combinations.  In IEC test the lines are cleared with 1,3 and 5, and set with 2,4 and 6 respectively.  So we will use that notation for the tests, and in all cases, probe pin 5, the data line.

The easy way

1581: pin 5 (data)

135 - HIGH 4.85 V

136 - LOW ~0V

145 - HIGH 4,85 V

146 - LOW ~0V

235 - HIGH 4.85 V

236 -LOW ~0V

245 - HIGH 4,85 V

246 - LOW ~0V

 

1581: pin 4 (clock)

135 - HIGH 4.85 V

136 - HIGH 4.85 V

145 - LOW

146 - LOW

235 - HIGH 4.85 V

236 - HIGH 4.85 V

245 - LOW

246 - LOW
 

1541: pin 5 (data)

135 - HIGH 4.53 V

136 - LOW

145 - HIGH 4.52 V

146 - LOW

235 - HIGH 4.52 V

236 - LOW

245 - HIGH 4.52 V

246 - LOW

 

1581: pin 4

135 - HIGH 4.51 V

136 - HIGH 4.51 V

145 - LOW (always at around 0.08V)

146 - LOW

235 - HIGH 4.51 V

236 - HIGH 4.51 V

245 - LOW

246 - LOW

 

So, those all look pretty much the same.  This makes me think that maybe there is still a CPU speed problem somewhere. If so, its rather odd, because I can run the freeze-combined.prg test programme, and while it isn't perfectly meta-stable, its accurate to 99.9% or so of C64 CPU speed (the only difference is we are not currently doing the write(s) of an instruction during the 3-cycle BA setup time).

Investigating further, we find that the first time trying to access the 1581 from C64 mode, we get a device not present error -- but 2nd time it works.  So we tried again from C65 mode, and now the 1541 is responding.  Nothing else has changed, except maybe that the 1541 has warmed up a bit.

Yes, and now its also responding from C64 mode.

Rechecking voltages on the 1541, its now upto about 4.86V, so we can't (yet) rule temperature out. But even if it is temperature, we need to know what is going wrong, so that we can actually make it work with all drives all of the time.

Anyway, this is all feeling weirder, although my gut still tells me that some timing issue is still not quite right, and is the cause.  The trick is how we can capture good and bad traces, so that we can play "spot the differences" and work out the problem.  One of those cheap USB data loggers and an IEC extension cable that taps them off might be a good path here. Again, not something I can easily conjure up in the desert, and if I don't get the Pi1541 working, I don't have a way to test anyway, so it will be depending on the rest of the team back in Germany to help me further on this one.

Another option is to use two MEGA65's connected via their IEC busses, with one sniffing and logging the bus traffic, while the other talks to the drive.  Alternatively, we could use something like Vivado Integrated Logic Analyser, that can log various signals to BRAM in the FPGA, and then later visualise them.  As the R3 board has more BRAM than the R2, there is actually some free BRAM, enough to be able to try this. But first, some sleep, then to think about the best path of attack.

But before I do hit the sack, we tested using a C64 ROM on the MEGA65, and also using drives set to device 11, and leaving the MEGA65's internal drive sitting on 8 and 9. And that DOES work will all drives. So it looks like we are tickling bugs in the C65's not completely finished DOS -- or the ROM patch to change the device number needs a bit of further tweaking.  But that can all wait for another blog post.

MEGA65 R3 PCB Testing

This week we have been testing all the changes made on the R3 PCB. The pain has been that we have a very tight time-frame for this, and I don't have one of the new R3 PCBs here with me.  

In short, we have to tell Trenz in the next day or so, whether there are any known problems with the board, so that they can order the bare PCBs in time for the DevKits to go out later in the year.  But COVID19 and logistics have thrown a spanner in the works, because I am here in the Australian Outback -- some 17,000km from the test boards in Germany -- and international freight is, shall we say, a little problematic at the moment.

So I am having to do the whole PCB bring-up stuff remotely.  Fortunately the R3 board is very similar to the R2 board, with just a few fix-ups in various places. The list of things that have changed in some way, includes:

1. Pull-ups included on all ports that were missing them on the R2.

2. POT line support on the joysticks, in a way that is compatible with the 1351 mouse and paddles.

3. SRQ line on the IEC port is now fully present.

4. Support for 2nd internal floppy drive on the 34-pin connector.

5. Internal speaker is now stereo, and using a different amplifier.

6. digital video / audio output now uses a direct FPGA connection instead of ADV7511 buffer chip.

(1) was easy to test: If the machine boots and works with joysticks and cartridges etc, without soldering anything on the board, then it is fine, which it is.

For (2), this was also fairly straight-forward, in that hooking up a mouse and testing it with a little BASIC programme is pretty simple.

(3) and (4) were also fairly straight-forward. The real problems with remotely testing are with (5) and (6), as I can't just poke and prod with my oscilloscope.  Even just checking if new registers are showing up becomes much harder.  We have had to coordinate across the oceans and time-zones, and do a lot of remote-desktop control, so that I can interact with the R3 PCB from afar:

To add to the fun, it looks like one of the three sample boards has a fault with the IEC port circuitry.

We have of course organised to send one of the boards here, but with COVID19, its really hard to predict when the board will make it here to Australia. Then when it does arrive in Australia, it has to get to where I live at the moment.  Normally I live in a large city, but not this year. This year for various reasons I am living in the middle of the Australian Outback. While this has a number of nice benefits, such as seeing pretty wild flowers, our fun lizards and other bush critters, and even a bit of opal hunting, as the following pictures show, it does also create some logistical problems...

Sturt's Desert Pea, the state's national flower, which is almost impossible to grow purposely, but sprouts up in the Outback, wherever it feels like.

Bearded Dragon warming itself on the road.

Edge-on view of opalised fossil cockle shell.

But back to those logistical problems...

I won't give my actual address here, but let's suffice by saying that it can be approximated as something like:

"The house the other side of the caravan park in the tiny village in the middle of the Outback, about 135 km from the nearest sealed road."

For the postal service, life is relatively simple: There is a private bag for the village (kind of a postal version of the old party-line phone lines), which gets picked up from the nearest regional centre (about a 6 hour drive away!), and then delivered to us on an Outback Mail Run twice a week.  While things might not be quite as tenacious as they were in the 1950s when Tom Kruse was the famous Outback Mailman, the posty still has to drive that 135km of rough, stony and corroguated dirt road.  

Where the post can go wrong, is if the post office in the city puts the post into the wrong private bag.  Then it goes to the wrong Outback Station, who hopefully realise and put it back into the next bag for collection by the posty.  That adds a week, then add another week for it to get back to us here. And that's assuming it doesn't sit on someone's mail shelf for a week or two, before they realise it isn't for one of their workers, and put it back in the bag, and then convince the post office to not put it straight back into their bag again the next week.  In short, the post can take upto 6 weeks to get here, if things go a bit pear shaped.  Even Tom Kruse was faster than that in his old Lleyland!

But for international couriers, its even more annoying: NO couriers deliver to Arkaroola, where we live. The tourist enterprise here has to ship their own supplies in, including all food, because they can't get any delivery service apart from the post. The nearest point that they will deliver is the end of the sealed road 135km away.

Fortunately we know folks who run the caravan park there, and they are kind enough to hold couriered parcels for us, and bring them over when they visit. So in theory we can get a parcel with the R3 PCB sent to them, and then get it over here quickly after that at the standard Outback surcharge of a cold beer. But first we have to get it to them...  And that's where COVID19 is playing jip with everything: International freight is quite impacted, so it might take a few weeks to get here. Or a few days. Noone can tell us, and DHLs tracking page is also not really telling us anything useful, only that the parcel has been cleared for departure from Frankfurt. 

And in the meantime, we continue to debug remotely...

MEGA65 Revision 3 PCB Samples For Testing

 Another exciting moment this week: We have the samples of the Revision 3 PCBs for the MEGA!  Pretty pictures follow, along with some discussion along the way.

First up, we can see that the PCB is quite similar to the Revision 2.  In fact, it has as few changes as we could get away with, while fixing various niggly little problems:

This view more from above shows that we have much nicer silk-screen artwork, clearly labeling it as a MEGA65, recognising Trenz, MEGA, and the MOULDS TEAM, the tiny entity we had to setup to handle the moulds funding stuff:
We'll cover some of these things a bit more in some of the photos coming up, but we can see here that there is an extra 2-pin connector on the right hand-side, so we can now support stereo internal speakers, complete with 2W amplifier, so you don't need to worry about having a monitor with speakers if you want to kit your MEGA65 out for easy party use:

A bit closer view of some of the connectors.  The keen-eyed will notice some changes to the digital video output area: We have changed from the ADV7511 display driver to directly driving the digital video from the FPGA, to solve problems we had with sound on the ADV7511.  The 3.5mm audio jack also has the pinout corrected, and works for stereo output straight up now:

The power switch and cartridge port area has been reworked to allow more room for super-wide cartridges, as well as adding missing pull-ups to the cartridge port and joystick ports:

And perhaps the biggest change, in terms of long-term effect, is that we now have an A200T FPGA instead of the A100T.  This means about 2x the logic capacity and almost 3x the internal RAM (BRAM) in the FPGA. This means we can support other more complex machines more effectively.  AGA Amigas should be absolutely no problem for example.

From the back, the main difference to see is all the nice pull-up resistors for the expansion port:

Back to the front, from top left going anti-clockwise, we have the internal SD card, PMOD expansion connectors, dual floppy power connectors, and the 34-pin floppy connector.  The floppy connector now has all the signals to support two drives connected at the same time:

Here we have the nice MEGA logo, and the keyboard connector above it.  The red connector and normal header are both connected together. This just gives us some freedom as to which style cable we use.  The keyboard header can also in principle host some simple expansions, as it has lines direct to the Xilinx FPGA.  Speaking of FPGAs, we also see the MAX10 service FPGA.  This FPGA does some power house-keeping, and also gives us the eventual posibility of making the main FPGA boot from a bitstream stored on the SD card, so that you aren't limited to what can fit in the 32MB flash that the Xilinx normally boots from. We also see the unpopulated JP21, which has 12 lines directly connected to the MAX10 FPGA, and can be used for internal expansions as well.  We're in the process of making a mechanism to remotely access that header from the Xilinx FPGA:

Here we have the monster A200T FPGA again:

As previously mentioned, we have the extra speaker connector to support stereo internal speakers. There are screw bosses in the injection moulded cases to accept some really nice 2W 31mm diameter speakers we found for using the in MEGAphone. We won't be supplying these in the MEGA65, but you have the connectors there to add some nice loud internal speakers:

Finally, we have the overall top view, before I sign out and start working in earnest getting the board fully tested, so that we can commit to manufacture for the DevKits!