It's been a while, but I have time and energy now to tackle some of the remaining tasks on the expansion board bring-up.
To start, I have inserted most of the missing ICs, except for the couple that require me to remove the internal drive in my MEGA65, because the space behind the drive is quite tight. If I haven't already, I should certainly move those two ICs further towards the back of the machine.
The two with daughter boards with all the resistors are 74HC165s with current-limiting resistors to make them 5V tolerant, because the 74LS165s I had originally designed it for turned out to be Unobtainium due to Chipageddon.
You can see the two I haven't populated yet here, wedged behind and under the floppy cable. To make matters even more fun, one of those is also one of the 74HC165s, and so requires the daughter board, which probably won't fit there. So when I go to test the tape drive port, I will likely have to remove the floppy drive.
As for the IC positions, it looks like I have moved them further back on the latest revision. It will still be close, and putting them in sockets will be a bit sketchy, but they should fit just fine soldered in. So no problem there.
Turning on the MEGA65 with all the ICs fitted has happened without incident: Nothing seems to be getting hot, and all the magic smoke is staying inside the chips. So far so good.
Next step is to make a test bitstream that handles the shift registers to read and write the various bits. As a reminder, the interface is just 4 pins for the main ports: Clock, Latch, Data Write and Data Read. When the Latch signal is high during a clock tick, the bits in the output serial buffers will appear on the appropriate pins, and the signal levels on the input pins will be read into the shift registers to be shifted out.
This means that to do a complete sequence of updating pin values and reading the result, we clock out each of the bits for the output registers, enable latch for one clock tick, which also them captures the input port bits, and then we read those out.
Looking at the datasheet for the 74xx165s, it looks suspiciously like I have got the serial port chain backwards, with the pin that I am using to read from being the one that should be the input from the previous IC, and as a result, nothing will get read. Fortunately, if this is the case, it will be fairly easy to fix, as I can just disconnect the pin at the PMOD connector, and run it over to the correct pin on the 74xx165 at the opposite end of the chain. To fix the PCB design, it also won't be too hard, as it just swaps pins 9 and 10 on the ICs. I've made and pushed this change in the PCB repo.
Now I just have to switch the pins 9 and 10 on the prototype PCB I have made for those 3 ICs. This is the same ICs that I have had to make the little daughter boards to add the resistors, so I should be able to modify those to switch the pins with a bit of luck.... Except that I have just discovered that I have completely messed up the pinout of those daughter boards. The resistors are not on the correct pins. So we can at least call this a "self-correcting stuff-up," in that through this other problem, I have identified this other problem. However, it's only half self-correcting, as I still need a way to protect the 74HC165s from excess current due to over-voltage, as well as swap pins 9 and 10 around.
First stop will be to see exactly what I have done with the daughter boards, and whether I can do some sort of bodge to fix those. If not, then I'll see whether it makes sense to design a new set of daughter boards to test, or whether its just easier to order a set of the corrected expansion board PCBs at a higher cost, but in the hope that I have now found and fixed all the remaining problems. I will need to get some of those fixed PCBs at some point anyway, for final testing, which is a vote in favour of that. But on the other hand, the risk is higher that I won't have found all of the problems, and will end up having to order even more PCBs after making further revisions.
Hopefully I haven't done something similar with messing up the cascaded shift register direction to the output chain of 74xx595's: Phew! Those look ok.The only other trick is that we have four output registers but only three read ones. But that doesn't really create any special problems.
Quite a few months have passed, since I last had time to work on this, during which time I did decide to get a new batch of boards with the known corrections made to them, which I'll start populating one of, with the parts I have on hand, and so that I know what parts I'm missing and will need to order. I'm keen to get the order in before Christmas, so that I have the parts here while I am on holidays over the summer.
Let's start by checking the physical fit of the board, as some holes got moved between revB and revC to fix poor fit. Generally speaking, it's much better, but there are still a few holes not quite in the right positions.
I've gone ahead and soldered on the resistors for the composite/component A/V connector, the connector itself, and the PMOD connectors. This should be sufficient to enable composite/component video. I need to pop out the connector holes in the case of the MEGA65 R5 I am using to build this in, then I can screw it into place with one or two screws for now.
I'm continuing with the assembly, and keeping track of parts that I do and don't have.
I am short some 1K and 3K3 resistors, which will be easy to fix at Jaycar Electronics tomorrow.
I have exactly the 4 74LS125s I require.
For the 74LVC165, we can substitute 74HC165s, as we have added 1K in-line current-limiting resistors. I have 4 of those, and only need 3, so that's good.
For the 74LS595s, I don't have stock on hand. So I've gone and ordered all the missing stuff and some spare ICs etc from digikey. Allegedly they should arrive in only a couple of days, as it is via Fedex International Priority at no extra cost. I'm a little dubious this close to Christmas (16 Dec), but who knows! This means I should have them all by the time I go on leave. I've got plenty of other stuff to do in the meantime around the house, so I'll just wait patiently for them to arrive, I guess.
And they did arrive before Christmas :) I've now soldered on the two ICs that have to be directly soldered, and installed all the resistors, except for the one related to the 6V line to the tape port, which I'll do when I also solder in the 6V DC regulator for the tape port. Here is how it looks right now:
Next step will be to create a module that handles this bus, and some automated tests using VUNIT for it, so that I can develop it as far as possible under simulation, before I incorporate it. After that it will be tying the input and output bits to the appropriate ports of the MEGA65 machine module in the VHDL. From memory, most of those are already exposed, so it shouldn't be too hard. I'll then also need something to connect to the user port to make sure that I can read from and write to all of the appropriate lines.
Okay, I have a first implementation of the 74LS595. Not sure if its correct, yet, but it is fairly simple:
signal sr : unsigned(7 downto 0);
signal q_int : unsigned(7 downto 0);
begin
process (rclk, srclr_n, srck, g_n, ser) is
if rising_edge(srclk) then
-- Advance bits through shift register.
sr(0) <= ser;
sr(7 downto 1) <= sr(6 downto 0);
-- Reset register contents
if srclr_n = '0' then
sr <= (others '0');
end if;
end if;
-- Allow for cascading
if falling_edge(srclk) then
q_h_dash <= sr(6);
end if;
if rising_edge(rclk) then
q_int <= sr;
end if;
if g_n='0' then
q <= q_int;
else
q <= (others => 'Z');
end if;
Now to do the 74LS165, which is the other way around: parallel in, serial out, which is just as simple:
signal sr : unsigned(7 downto 0);
begin
process (clk, q, ser, sh_ld_n, clk_inhibit) is
if rising_edge(clk) and clk_inhibit='0' then
-- Reset register contents
if sh_ld_n = '0' then
sr <= q;
else
-- Advance bits through shift register.
sr(0) <= ser;
sr(7 downto 1) <= sr(6 downto 0);
q_h <= sr(7);
q_h_n <= not sr(7);
end if;
end if;
That just leaves the 74LS125, which is even simpler, as its just a non-inverting tri-state buffer:
process (a,oe) is
for i in 0 to 3 loop
if oe(i)='1' then
y(i) <= a(i);
else
y(i) <= 'Z';
end if;
end loop;
end process;
So now I should be able to make a simulated version of the two serial rings on the board: One for reading pins, and the other for setting them.
I'm going through plumbing up the simulation identically to the schematic. In the process I found I had one pin labelled incorrectly on U4, which resulted in a missed wire between pin 1 of U4 and pin 16 of U3. I'll have to put a blue wire on my prototype board to deal with that. Fortunately with all hole-through, that will be trivial. What's even better, is that it will be easy to route it on the PCB for subsequent batches:
It's that white line. So let's route it...
Nice! I only had to slightly move one wire. Post a comment if you can spot the difference :)
Okay, back to building up the VHDL simulation of the board...
Next thing I've noticed: I'm using 74LS/HC595s, which are tri-state, not open-collector. I probably really intended to use open-collector outputs, so that we don't end up with the possibility of cross-driven lines. The only thing is that to change to a 596, we would need pull-up resistors on all the outputs, which is a bit of a pain, as it would require a lot of re-routing in all likelihood. Oh, no, it's fine and a false-alarm. There are only a couple of lines that this applies to, and they are lines that are, I believe, strictly output only: PA2 and PC2. Everything else has a 74LS125 tri-state buffer on it.
Hmmm.. Maybe I could have reduced the part by using 74LS596s, and then I wouldn't have needed the 125s? That does seem rather likely, you know... Well, maybe if I get all excited and want to do an overhaul of the board, because that would be quite a lot of re-routing.
Anyway, back to the plumbing in VHDL: It's normal to expose the output enables, outputs and inputs all to the top-level of the VHDL model, to avoid problems with synthesisers getting the wrong idea. So I probably don't need to hook up the 74LS125s in the VHDL.
With a bit of fiddling, I have the test harness all hooked up an running a dummy test. Now to write some actual tests.
Probably the best form of test is to implement the host-side of the controller that interfaces with the simulated side, and confirm that bit patterns on the host side show up on the simulated side within the appropriate number of clock cycles. That should be sufficient, as it really doesn't do anything more than that. The expansion board in that regard is really quite unintelligent.
I'm making some good progress on this front, first testing that we can control output signals. The tests generally look like this:
elsif run("TAPE_WRITE is correctly conveyed") then
wait_for_ring_cycle;
remember_current_signals;
r_tape_write_o <= '0'; tape_write_o <= '0';
wait_for_ring_cycle;
compare_with_remembered_signals;
remember_current_signals;
r_tape_write_o <= '1'; tape_write_o <= '1';
wait_for_ring_cycle;
compare_with_remembered_signals;
The tests make use of three functions:
wait_for_ring_cycle allows enough time to go past, to make sure that the signals all get updated.
remember_current_signals remembers the current state of the signals.
compare_with_remembered_signals checks that the output signals still match the remembered signal states.
A test then consists of remembering the current signal state, changing some signal, and it's "remembered" value to what we expect it will be, allowing the ring to update all the signals, and then checking that the new state matches what we expect, as stored in the (modified) remembered state.
Now to replicate that for all of the output signals we have, and if that passes, then we will have confidence that the output side is all working properly -- which I have done without great difficulty:
==== Summary ====================================================================================
pass lib.tb_exp_board_serial_rings.EXP_CLOCK ticks (0.5 seconds)
pass lib.tb_exp_board_serial_rings.EXP_LATCH is asserted (0.5 seconds)
pass lib.tb_exp_board_serial_rings.TAPE_WRITE is correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.DATA outputs are correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.DATA output enables are correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.tape_6v_en is correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.c1565_serio_o is correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.c1565_serio_en_n is correctly conveyed (0.6 seconds)
pass lib.tb_exp_board_serial_rings.c1565_clk_o is correctly conveyed (0.6 seconds)
pass lib.tb_exp_board_serial_rings.c1565_ld_o is correctly conveyed (0.6 seconds)
pass lib.tb_exp_board_serial_rings.c1565_rst_o is correctly conveyed (0.7 seconds)
pass lib.tb_exp_board_serial_rings.user_pa2_o is correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.user_sp1_o is correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.user_cnt2_o is correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.user_sp2_o is correctly conveyed (0.6 seconds)
pass lib.tb_exp_board_serial_rings.user_pc2_o is correctly conveyed (0.6 seconds)
pass lib.tb_exp_board_serial_rings.user_cnt1_o is correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.user_atn_en_n is correctly conveyed (0.5 seconds)
pass lib.tb_exp_board_serial_rings.user_reset_n_en_n is correctly conveyed (0.5 seconds)
=================================================================================================
pass 19 of 19
=================================================================================================
So now onto the input ring :)
Setting up the plumbing, I noticed another errata: I had two pins to read the CNT1 pin, which doesn't matter. I have removed the duplicate.
What might be an issue, though, is that the 74LS165s shift when EXP_LATCH is high, and latch when EXP_LATCH is low. This is backwards to the 74LS595s, and means I might need to effectively halve the sample rate, because I will need to leave EXP_LATCH for 24 ticks instead of 1. But I need to read the datasheets more closely, as it might be that I can leave EXP_LATCH high most of the time, and then just bring it low for one cycle, if the 74LS595s are edge triggered, rather than level triggered.
The EXP_LATCH behaviour was fine, with the method I described above. With that done, and all the signal plumbing in place, and the unit tests updated to handle it, the end result is that the expansion board controller is able to set and sense all bits for all ports. That is, it looks like the wiring of the rings is good, and I have a controller than can use them. There is a remaining niggle about the timing of the serial shift register chips I am using, but I suspect it's just my imagination. The real test will come from populating the board and trying it out.
To make the trying it out much easier, what I should work on next is plumbing the expansion board controller into the MEGA65 core, so that I can easily do this. To make that in turn easier, I might make some VHDL records for the various ports, so that the amount of plumbing I have to wire is one per port, rather than one per signal. This will be especially handy since I will need to add support for this expansion board to MEGA65 R2 through R6, so minimising the work required will be good, and reduce the chances of error. I've now done this, and am ready to begin plumbing it into the MEGA65 architecture.
I had thought about burying the controller deeper into the VHDL, so that the changes per target would be very minor, but that would not work if we later made an FPGA board that had more lines available to control these ports with lower latency.
I've plumbed it all in for the tape and user ports in the MEGA65 R5 target. The C1565 port can wait for now, as can the other targets.
Hooking this up, I was reminded of something I had totally forgotten: The tape interface is not entirely on the CPU: The read line from the tape actually goes to the /FLAG pin of one of the CIAs.
I also found that the /PC line of the CIAs is output-only, so we can shave a few more parts.
Otherwise, the main thing I am contemplating is when the expansion board is not connected: Will the simple ring protocol make the MEGA65 think that various lines on the user port are being pulled low, for example, if they are not being actively driven. But first, I need to get everything plumbed in.
I now have it all plumbed in, but at least one user port line is appearing to be pulled low, which blocks the C65 ROMs from booting. I've seen this before, and forget the particular line involved. To counter this, I have added logic that attempts to check for the presence of the expansion board, however it doesn't seem to be effective right now.
More the point, I can't see the clock and latch signals on the PMOD. That was caused by an old clock line hanging around that I used by mistake, and was not really a clock. Resynthesising with that fix, and hopefully that will get both issues resolved: The clock will tick, and the expansion board detection will work to prevent lines being pulled low that shouldn't be.
The logic I am using to detect the board checks if the input ring is reading all zeros or all ones. If either is true, then it assumed the board is not present. I'm going to add a couple of small changes to the PCB to ensure that this detection scheme will never ignore the board when it is really present: I'll tie one spare input high and another low, so that the input vector can never be all zeros or ones.
It doesn't need much change, just this:
The only change on the PCB layout is to connect pin 11 and pin 16 of this IC together, which I can quite easily bodge on the board I have here. So that's two little changes I need to make now:
1. pin 1 of U4 and pin 16 of U3
2. pin 11 and pin 16 of U7
3. pin 12 to pin 8 of U7
Anyway, back to finding out why the C65 ROM gets stuck, I'll start by comparing the status of the CIA connected to the user port with and without the expansion board controller wired in. Hopefully there will be something obvious.
CIA2 registers with the expansion board controller connected:
:0FFD3D00:07FF3F00FD5BC5B000394500FF03C141
and without, with differences highlighted:
:0FFD3D00:07FF3F00A7FDBCFE06040000FF03C141
Actually, that bitstream also hung. It's all a false alarm! I had a 1541 connected, but not powered on to the IEC port, and that causes this behaviour.
So it boots to BASIC just fine now :)
Time to put those bodge wires on, and populate the expansion board with the remaining ICs and start testing it!
Ok, bodge wires in place: I've just used convenient spare pins on the shift register, rather than following
So the next step is to give it some power from a current-controlled power supply, and make sure that it doesn't want to suck lots of current and turn it into smoke.
Current controlled power supplies are great for this kind of thing, because you can set the allowed current super low, and then slowly increase it until either it gets higher than you think it should, or the voltage reaches the correct level, at which point you know it is drawing all the current it wants. This lets you spot problems before you fry things -- like when I put one of the ICs in backwards just now ;)
Anyway, I have all the ICs fitted, and current checks are fine, so I should now be able to put it into my machine without great fear and trepidation. Which reminds me, one of the little easter eggs I included in this board design is the ability to move the TE0790 JTAG adapter so that it can poke out the tape port hole (and still leave enough room to connect a tape drive at the same time). This means you can easily connect and disconnect the JTAG USB connector, without having to open the case, like this:
My only concern is whether the internal extension lead that it will require will be too long, and might cause trouble with the relatively high-speed JTAG lines. The serial monitor interface, however, should definitely be fine. We'll just have to suck it and see... and it does! Both the serial and JTAG functions still work, despite me having to use a rather longer cable than necessary. It also just looks quite nice and neat and tidy from the outside:
Okay, so now I have everything connected, with all the temporary cables I have rigged up. For production, we would get some cables custom manufactured, that would be much easier to connect, and much neater and tidier as well. But for now, I'm just interested in functionality... and that no smoke comes out ;)
Well, no smoke has appeared, so that's good. In theory at least, I should now be able to control and sense the user port pins, as well as the tape button state (I haven't connected the tape motor control yet).
So let's try to see if we can read the TAPE_SENSE line. This line goes high when the tape PLAY button is pressed. I'm not immediately seeing signs that it is being recognised. Probing the board at R23, which is the 1K current-limiting resistor in-line with the TAPE_SENSE line, the output side goes from 2.4V when not pressed, to 3.66V when pressed. I'm suspecting that the 2.4V when inactive is too high, resulting in it always reading high.
Yes, reading through the schematics for the datasette, the sense line is indeed expected to switch between ~2.4V and ~5V. The 74HC165s I am using require the low voltage to be below 1.35V, so I'll need to do something about that. Probably the easiest approach is to put a couple of diodes in-line, so that the voltage drop across them gets it below 1.35V. Or better yet, a 3.3V zener diode so that I can just block the ~2.4V completely, but let the 5V through (still via the current limiting resistor).
Now the question is whether I have a zener diode handy, or if I need to go for a quick ride over to Jaycar Electronics to get one. More the point, whether I can find one in my stuff. I suspect I do have some. I think a Jaycar visit will be required...
In the meantime, I can test the tape motor control, through. And that works :) That's actually really encouraging, because it means that the output control ring is working, and that it is in the correct position in the ring and that I have it all correctly plumbed through. So when I put the zener diode in, I can also install the 6V regulator for the tape motor, which is the only active component I had left off for now.
Before I do that, I would like to test the user port pins as well. I thought I knew where I had a user port connector, but I can't find it right now. The data lines are easiest to test, but those are annoyingly on the underside of the connector. So it will take a little bit of gymnastics to be able to easily probe them. So I'll just finish fixing the tape port stuff first.
I've added the 3.3V Zener and also installed the DC-DC converter. I had every expectation that this would fix the two problems I was seeing, but at best it has just changed them, which is quite frustrating. The tape motor enable line is still being correctly driven, and I can probe it at the DC-DC converter.
Well, the first half of the problem was I had the DC-DC converter turned around the wrong way. Fortunately I hadn't soldered it in, as it is a decent press-fit. Also it turns out this model of DC-DC converter, which is not the exact one I had originally planned to buy, does not work without a trim resistor fitted. I couldn't find any 220 Ohm resistors at Jaycar, only 240 Ohms, which will give a voltage of perhaps 5.5V instead of 6V. I don't know if that's enough for the tape motor to run or not. I guess I'll give it a try, or do some resistor combining to get closer to the right value. By sheer good luck, putting a 3.3K Ohm resistor in parallel to a 240 Ohm resistor yields almost exactly 220 Ohms, and I have a bucket of 3.3K Ohm resistors. So I'll do that.
And it looks like I might have the Zener diode around the wrong way, too. Fortunately I bought 2 of those, if it proves a bit tricky to remove without destroying it.
So I guess it's back to the soldering station to try to fix these things.
Ok, diode orientation switched, with no effect. Not yet sure what is going on there.
With the trim resistor fitted as 240 Ohm and a 3K3 Ohm in parallel, the output voltage is about 4.5V, instead of 6V. That's too low for the motor. Maybe my push-fit arrangement is adding too much resistance to the terminals of the DC-DC converter, and it is reading the trim resistor as somewhat higher. On the plus side, I can switch it on and off via the motor control bit of the CPU port, so that part of things is still fine.
Fiddling around with the DC-DC converter does yield odd effects, so I'm guessing that I do just need to bite the bullet and solder it in place.
Okay, with the DC-DC converter soldered in place, it is indeed switching between ~0V and 5.98V, with a nice smooth level. So that's all good. Except that the datasette motor doesn't run. It's possible I fried it earlier, but I'm not convinced. I dug out a 2nd datasette, and that also does nothing. So I don't think its fried.
So how was the motor running before? Is it that 6V flat DC isn't sufficient voltage? Was it some ripple on it that was required?
I had a chat with Gideon to see how he does it on the Ultimate64 to see if there were any clues about the required voltage. He uses 6.3V, which I can't easily get with the DC converter here. So then I had the idea I should have had a little while ago, to test the datasette motor with my voltage controlled power supply: It runs fine on 6.0V.
A bit more digging, and I discovered a silly error I made on the schematic: I didn't connect the GND pin of the datasette connector. Another bit of blue wire will fix that fairly easily... and that indeed gets the motor stopping and starting when it should.
It might also help this problem with the SENSE pin, since without a GND reference, that would have been all wonky, too. Nope, that's still not responding. But I think the problem there now might be that I have fried the diode one way or another. So I might remove the diode, or at least break the circuit with it, and see what the sense line does now that we have GND connected.
Hmm.. The sense line now seems to be stuck on 0V. Reading the C64 schematic, it looks like the SENSE line needs a pull-up resistor, as does the tape read line, so I should add those in. In fact, I can just pull them up to 3.3V instead of 5V, and ditch the whole zener diode thing. So where did I get the idea that tape sense floated to 2.4V? I'm sure I had read it somewhere, but looking at the schematic for the datasette, it is definitely just pulled to GND when a button is down.
With the pull-ups TAPE_SENSE does indeed switch between 0V and about 2.6V -- which is the voltage the 3.3V rail has sagged down to. That makes me think that there might be excessive current draw on the 3.3V rail for some reason, so I had best investigate that.
Investigating the 3.3V rail problem, it seems to have sagged even lower now, down to <1V. I'm wondering if I haven't shorted something previously, and now they are in thermal recovery (and hopefully not totally fried).
With the current controlled supply, the board is only drawing 20mA or less, so if there was a short-circuit, it was earlier. I might just leave everything off overnight, and see how it fares in the morning. It will be a pain if I've killed the 3.3V regulators for the PMODs on the R5 board here. I can at least in the interim power it from the current controlled supply, though, so it's not a total show-stopper.
The power rail for the PMODs is generated by U35, which is convieniently near them and on the top of the board, so I can try to figure out what is going on with it. It's also a part that could feasibly be replaced by hand, as it's only an 8-pin surface mount job with legs, rather than a little BGA. But it might have a thermal transfer pad underneath, which would be a pain.
Looking more at the part, which is an AP2196, they are actually designed to prevent short-circuits, and have thermal protection among other things.
Ah! On the R5 board, pull-downs were added to disable the 3.3V rail on the PMODs by default. I'll have to fix that. But at least that's a nice simple explanation, and means that I probably haven't toasted anything... and that fixes that!
Now, the other thing I remembered for reading the TAPE_SENSE line, is that the data direction bit in location $00 has to be set to input to be able to read the line. With that, I can now read the TAPE_SENSE line via the CPU port at $01.
So... I think it should all be set and ready to try to read something from a tape. I'll give that a go in the morning, because it's got late now.
It's tomorrow, and I have prepared a stock C64 ROM for the MEGA65, and put an old Zzap64! cover tape in the datasette, and tried to load it. And the result was partial success, as seen below:
Done -- and while it then refused to find or load anything on that datasette, I put the tape in the datasette in which I found it, and it finds the first game on the tape :)
But switching to the other deck, it starts loading, and as I type, I am watching the raster bars of the tape fast loader that is used on the tape:
Just the fact that it shows the correct name proves that the TAPE_READ line is working to a pretty good approximation -- the only question will be whether the timing accuracy is good enough, which I will be able to prove empirically when this finishes loading -- if the game runs, then it has to be fine. If it doesn't run, it will be less clear-cut, as it could be that the tape has rotted, or the game doesn't work on the MEGA65 or who knows what.
But all such fears can be ignored, because the game has loaded fine!
That's it for this post, I'll keep working on the user port and other remaining things in the next episode.
No comments:
Post a Comment