05/16/2020 at 22:21 •
It's been another dizzying couple of weeks on the rosco_m68k project, with lots of community activity going on, Tindie orders to ship and more stock to source, but I've still had time for some good old-fashioned hacking. I've been focusing on the video card mainly, and it's now at a point where prototype boards are ordered and have been shipped by JLCPCB.
In it's current state, the board looks like this:
(Well, it's changed a bit since that photo as the video RAM at bottom right understandably didn't work in this configuration :D)
The centrepiece here is the V9958 (on it's SDIP->Breadboard adapter centre right), supported by a couple of 16V8 GALs for decoding and glue, all hooked into a prototype bus board (top left). The main board is top-right. I was pretty impressed it worked at all, and it took a little tinkering to get it going, not because of issues with the design so much as issues with breadboard in general.
To begin with, I didn't have any suitable DRAMs, so while I waited on their arrival I decided to try hooking up an old (battery-damaged) Amiga trapdoor expansion PCB to see if it would work. Results were encouraging:
Obviously it's not quite there, but there *is* some output, so I knew I was heading in the right direction. Again, the ability to prove this out in MAME was a massive help, this is what the screen above looked like in the emulator:
Eventually the DRAMs arrived, which is when I took the shot of the board you saw in the first picture. This improved things somewhat, but also made other things weirder:
(all the H's are deliberate, I changed the character I was clearing the screen with to check I was actually writing the DRAM - MAME couldn't help here as it was all about cycle times and refresh).
This is the point where I took the first picture in this post, where the DRAM was tacked on to yet another breadboard and jumper wired in. Of course I suspected this to be the problem, and sure enough, after moving the DRAMs onto the same board as the V9958 itself and making sure the wiring was sound, I was finally able to get a decent "Hello World" out of the VDP!
With this success, I finalised the schematics for the prototype board with some input from everyone over on Discord, and drew up a quick board design to send off for manufacture. It's on it's way, and I'm really looking forward to building it and proving the design before moving onto the final design of the board.
The PCB is quite compact (it's a prototype, and I'm working hard to keep prototype costs to a minimum after spending far too much on prototype RAM and bus boards):
The final design is going to incorporate some great community suggestions (like the amplified RGB and sync signals going to the header as well as the DIN, and the colour bus being on a header too), but for now I just want to make sure the basic thing works, and this will do just that.
05/07/2020 at 18:29 •
Whew, it's been a busy couple of weeks here on the project, with lots going on and lots to update, so I'm going to give a quick rundown here of the main developments that have been happening.
Tindie launch - response has been amazing!
It's almost a month since the rosco_m68k launched on Tindie, and I've been amazed by the response! I honestly wouldn't have believed back when I started this project that anyone else would be particularly interested in it, but it seems like it's going to be a modest hit, and I'm super grateful to everyone who's ordered one, or added them to their wish lists - thank you all so much!
Rest assured that the money from sales will be put to good use designing new expansions for the rosco_m68k, expanding the software, and generally making it better all the time. A V9958 video board is already in the works (more on that later!), a RAM expansion has launched today and there's a new local-bus / backplane board coming real soon (just needs one more spin through manufacturing to correct some minor issues).
Once again, huge thanks to everyone who's already built their very own brand new, really-old computer, and if you haven't got yours yet but would like one, you can find it available now on Tindie.
Community is growing!
Now the rosco_m68k is "out there" and people have jumped on board, it's been great to see a bit of a community growing around it. It's truly awesome getting together with people and hearing their plans and ideas for the computer, things they want to try and new stuff they want to make.
We're using Discord as a place to meet, and it's great to see people there who have been long-time friends of the project since the breadboard days here on Hackaday as well as new faces. If you'd like to get involved we'd love to say hi - find our server at https://discord.gg/zGUB7R8 .
The computer has an emulator!
Speaking of community, @Micko_mame joined Discord after building his rosco_m68k kit, and hasn't stopped amazing me since with the things he's doing with software. As a developer of the MAME emulator, Micko knows his way around the source of that project, as he demonstrated with a real mic-drop moment when he posted a picture of the rosco_m68k firmware and examples running in the emulator.
I cannot understate how awesome this is, debugging on a single-board computer with no kernel and only serial IO can be a challenge at times. Micko's MAME fork will really speed up the software development, both by reducing the compile-run loop time and allow single step debugging in a nice window, as seen in the shot above.
This really came into it's own recently when I was writing the initial bootstrap test code for the V9958 - writing to registers and especially to VRAM can be a bit challenging on that chip and it's hard to know if the code actually does what you think it does. Of course MAME supports the V9958, and Micko did the necessary wiring to expose it to the rosco_m68k target, and we were off to the races. Just being able to peek at VRAM and the V9958's registers saved a ton of debug time.
You can find Micko's MAME work in his fork on GitHub and trust me, it's well worth checking out - it supports RC2014 too if Z80 is more your thing than m68k :)
We are running MicroPython(!)
Another of Micko's mic-drop moments was when he announced (pretty much on day one!) that he'd gotten MicroPython running on the rosco_m68k! This is awesome on so many levels - I mean, it's a 68k running Python for one thing, but it also could open the door to a really nice machine monitor, written in python (with some assembly/C glue of course) and driven from the Python REPL. I'm super excited to start playing with it (I've sadly been head-down packing orders for shipping, frantically sourcing components and designing the V9958 expansion, but I'm going to be getting back to some software this weekend).
To get this running, Micko also had to do a minimal port of Newlib, no small feat when there's no OS, no memory management, and only serial IO.
Check out the code here: https://github.com/mmicko/micropython (on the mc68000 branch).
Larger Roms & V9958
@RTS4E75 (geddit?) also joined in on Discord, and though he's been waiting a while for components and free time to build his computer, he's already got a lot of great ideas.
For a start, he immediately noticed I'd done something a bit silly when designing the revision 1 PCB, and failed to connect some address lines that would have let the rosco_m68k easily support larger ROMs that have the same footprint as the 16K that's fitted as standard. My bad, but once he's fully up and running with his board he's going to prove out the idea, and if it works I'll be fixing the problem in a future board revision. The current thinking is that 64KB total should be doable without any real design changes, and maybe even larger with a jumper or two to change how some of the lines are connected.
Along with long-time friend of the project @henk.gooijen, RTS4E75 has also been involved in a lot of the conversations about the next hardware steps, especially the design of the V9958 and how it'll interface to external displays. I'm really looking forward to getting the V9958 on a board and really playing with it - right now I have a breadboard(!) circuit with barely working video RAM (an old Amiga expansion hacked in as the DRAMs I ordered haven't turned up yet :( ) but there's still the MAME emulation I talked about earlier so it won't stop the work on the software side.
It's a known fact that stuff designed with input from people is always better than stuff designed in isolation, so I'm really lucky to have everyone involved :)
So, as I said, it's a busy time on the project, but I'm loving every minute of it, and I can't wait to build the next thing. There are so many ideas being floated at the moment (including floppy/HDD storage, ROM monitors / debuggers, and all kinds of other things) that I'm more excited than ever about the future of the project.
And, once again, thanks to all who've already built their rosco_m68k, as well as anyone who is thinking about getting one - you're all totally awesome!
(Both images posted in this log came from and remain property of Micko)
04/27/2020 at 02:02 •
I had a little time this weekend, so I finally made a start with the V9958s I received a couple of weeks ago. I've not gotten all that far, but I have sanity checked that I can power the chips and hook them up to the bus on the rosco_m68k. As is tradition on this project, I want to develop the thing on breadboard before committing to a design (especially given the 9958 is completely new to me) but there's a hiccup - the V9958 comes in a 1.77mm pitch "Shrink DIP" package, which obviously isn't breadboard friendly.
I looked around on the nets for an adapter, and while I did find one (that was oddly enough designed for the V9958 and included the crystal and caps) it didn't ship outside the US. I also found a generic SDIP64 to breadboard converter on Amazon, but that one was out of stock. No matter, I fired up KiCAD and ran off a simple adapter in PCBnew:
I did this about ten days ago, and JLC had it back to me in a few days (I guess because it's such a simple board, in green and quite small, they were able to panel it more quickly than my usual oddball-sized-and-shaped-boards-in-blue) and of course it works great. In the pic above I've attached power and the clock - later I hooked up the bus and was able to get the chip talking to the computer in a rudimentary fashion. Because of the width of the adapter it doesn't fit 'normally' into the breadboard, and has to straddle the power rail of two side-by-side boards, but that's no problem.
I have a bunch of these little adapters, so if anyone is doing anything breadboard-based and needs to work with a wide SDIP of up-to 64-pin, let me know and I'll list them on Tindie for around $5 including shipping.
04/20/2020 at 22:00 •
With their usual speed, JLC got the RAM boards manufactured and shipped to me before I'd had chance to gather all the components (I'm still waiting on some right-angle pin-header sockets), so I quickly soldered one up to test it out and happy to say it works perfectly. Here it is hooked up, in the 2MB configuration:
I'll be offering this on Tindie soon in case anyone else wants to expand their RAM. Do you need a RAM expansion for the rosco_m68k? I mean, this thing supports 4MB (and you can technically have more than one connected, though I haven't finished the bus board design yet) - no-one could ever need that much RAM, right? :D
In other news, I'm finally seeing some movement on the 68010's I ordered a few weeks ago. After quite a bit of back and forth, I'm reasonably sure that these are the real-deal (not like the fakes I unfortunately picked up a month or so ago). Pictures have been sent, date-codes have been checked and assurances have been given, so all that's left is to actually receive them and test them. Needless to say, if they aren't genuine I'll unfortunately have to keep holding out for CPU stock for Tindie orders. That said, I have a good feeling this time around (and I have some backups on order too, just in case ;) ).
04/11/2020 at 22:20 •
So, I'm having a busy weekend here, having just launched the rosco_m68k on Tindie I've spent some time putting together my first few orders (thanks all who've ordered so far!) but luckily I've still found plenty of time for hardware hacking.
I've been busy working on the first expansion board for the computer, which is going to be a RAM expansion. I'm thinking of making it configurable for either one or two MB of expansion RAM, and where it maps into RAM will be configured by jumpers. The prototype is mostly working great:
In this picture it's still using a couple of 7400-series ICs for address decoding, but I'm replacing them with an ATF16V8BQL which will make it easier to support the jumper configuration and such and will save space when this thing becomes a PCB. I'm probably also going to make a simple bus-board to break the expansion bus out to multiple connectors. I feel like doing that now, and making the first expansion compatible with it will save frustration later.
Speaking of the 16V8 I've finally bitten the bullet and converted the WinCUPL code for the address decoder and IO glue to GALasm (not the original link, but the one I used). I've been meaning to do this for a while, because WinCUPL just deeply and severely sucks, and it only runs on Windows (as you might have guessed from the name) but because I've not really done anything with the CUPL since I first wrote it, I've just kept putting it off - it's good that I've finally had need to make some changes and do some new GAL code as it's spurred me on to finally do the conversion.
I've not added GALasm to the Home-brew tap I created to house to m68k GCC toolchain, because I figure that most people will want to recompile the GAL code (I include the Jedec files in Git anyway) so it would just add bloat...
While I was busy working on the RAM expansion, these turned up:
So it looks like I'm going to be ever busier than I expected I would be this weekend. I can't wait to get started with these but I don't have the breadboard adapters back from JLC yet (these are shrink DIP packages), and in any event I want to finish off the RAM expansion so these will have to wait a day or two :)
04/07/2020 at 19:59 •
I'll keep this one brief as I've already written a long post about it elsewhere (all the gory details can be found there), but I spent far too much of the weekend making an Arduino talk to the rosco_m68k as an IO expansion (i.e. mapped into IO space and communicating with the CPU over the bus).
This exposed a(nother) couple of issues with the board - IODTACK really needs to be exposed on the expansion connector, and the glue logic is a bit quick to drop DTACK when an address in IO space is no longer being strobed, but generally speaking once I'd figured those things out it went pretty well and I was able to get the Arduino to act as a simple single-register, write-only device connected to the m68k.
The timing issue probably won't affect real hardware devices, and the IODTACK issue can be easily worked around so no need to re-do any boards at the moment, though I've raised issues on GitHub to address them at some point in the future.
04/07/2020 at 17:42 •
So I'm currently gathering parts to hopefully start offering kits on Tindie, and while most of the bits can be ordered directly from Farnell, some are more tricky to get hold of - especially the MC68010 and MC68901, since they're no longer in production. So I resorted to eBay, and received the first shipment of six MC68010s today. On opening the package, I was.... suspicious.
These are the six ICs I received. On the right is a genuine MC68010P10. On the left are five that are either fake, or just rebadged, 68000s. The things that immediately made me suspicious:
- The Motorola logo is incomplete
- The font isn't right
- The date code suggests these were made in week 1, 2019 (or possibly 1919!)
You can't see it in this picture, but the surface of the ICs is also rough, suggesting the original markings have been removed.
Sure enough, I threw them into a board and ran a quick software test which verified that these are, in fact, 68000s. They seem to work fine as 68000s, but trying to do anything 68010-specific (setting the VBR in my tests) results in an immediate illegal instruction exception.
Fake ICs are sadly a fact of life, and luckily I'm working with my own design which explicitly specifies the 68010. I know that people buy these as an "upgrade" for Amigas and such, and I worry that people who do that will likely never know they're running a fake, as the software for those computers won't usually use any 68010-specific features.
This bit of code will check whether you have a 68010 or not:
movea.l into VBRmovec.l A0,VBR ; ... and load
If run on a 68000, this will cause an illegal instruction exception.
Because I felt like verifying that setting VBR actually worked too (unlikely it wouldn't I guess but y'know, completeness), I decided to expand this a bit to check these chips on the rosco_m68k:
MFPBASE equ $F80000 ifd REVISION_0 MFP_GPDR equ MFPBASE+$01 MFP_IERA equ MFPBASE+$31 MFP_IERB equ MFPBASE+$09 MFP_ISRB equ MFPBASE+$05 else MFP_GPDR equ MFPBASE+$01 MFP_IERA equ MFPBASE+$07 MFP_IERB equ MFPBASE+$09 MFP_ISRB equ MFPBASE+$11 endif section .text ; Entry point here! kmain:: move.w #$2700,SR ; Disable interrupts movea.l #$20000,A0 ; Use $20000 as vector base... movec.l A0,VBR ; ... and load into VBR move.l #TICK_HANDLER,$20114 ; Set up tick handler move.w #$2000,SR ; Re-enable interrupts .LOOP bra.s .LOOP GENERIC_HANDLER: rte TICK_HANDLER: move.l D0,-(A7) ; Save D0 move.w $408,D0 ; Read SDB byte 8 tst.w D0 ; Is it zero? bne.s .TICK_HANDLER_DONE ; Done if not ; counted to zero, so toggle indicator 0 and reset counter bchg.b #0,MFP_GPDR move.w #25,D0 .TICK_HANDLER_DONE: sub.w #$1,D0 ; Decrement counter... move.w D0,$408 ; ... and write back to SDB move.l (A7)+,D0 ; Restore D0 move.b #~$20,MFP_ISRB ; Clear interrupt-in-service rte ; We're done
(full code here)
Right... Back to trying to get hold of some CPUs for these kits I've been talking about.....
03/29/2020 at 19:01 •
The revision 1 PCBs I mentioned previously took about a week to arrive from JLCPCB, and I'm just as happy with them quality-wise as I was with the revision zero boards. They also represent the first boards that were designed (well, updated) in KiCad and exported for manufacture from there, and I'm pleased to say there were no unforeseen issues. I'm really liking KiCad now I've gotten used to it, and don't miss EAGLE at all.
With this milestone passed, I'm looking to start offering the computer in kit form on Tindie! The first iteration will be a sort-of "dev kit", in that it will be most suitable for hackers and devs, and I've been hard at work getting the software tidied up in preparation for that. The kits will come pre-loaded with the serial boot loader firmware and I've put together a "starter project" to easily spin-up an assembly or C project that's compatible with that so it'll be really easy to get started with the board.
That said, it's not all work and no play - I've also spent a bit of time porting some recreational software. Here's a screenshot of Jeff Tranter's 'Adventure' running on the r1 board, loaded via Kermit:
With lots of new development in the firmware and software, as well as the hacker-friendly improvements in the revision 1 board (GPIOs, timers, external interrupt capabilities and compatibility with "legacy" MC6800 peripherals included!) there's a lot of fun to be had with this board. I hope to be shipping kits in the next couple of weeks, and will update here as soon as I can.
Oh, and before I go, here's how the revision 1 looks when populated and working:
With this revision of the main board done, I'm turning my attention to peripherals. I already have a couple of graphics chips to play with and have ordered a few bits for experimenting with mass storage too, so watch this space for lots more development to come!
03/17/2020 at 22:20 •
Just a quick update to the previous log in which I talked about having made a start on the revision one design: I've now finished it and sent if off to the fab!
This revision includes a bunch of improvements, including:
- An improved expansion connector with support for MC6800 (legacy) peripherals
- A new IO and panel connector with GPIOs, software controlled timers and dedicated blinkenlight pins
- Doubled clock rate for the UART (allowing up to 9600 baud in the super-reliable divide-by-16 mode, or 115200 in fundamental, though YMMV here).
- Improved board layout (both in terms of place and route)
- Fixes for some silly mistakes in revision zero
This incorporates a number of suggestions made here in the discussion, so thanks to @Ken Yap and @henk.gooijen for those (not all of the suggestions made it into this revision but they're not forgotten!) and also to @paulvdh who took the time to help me import the project into KiCad and get started with it - I'm absolutely hooked now, and hardly miss EAGLE at all!
The new boards should be here next week (global pandemic permitting), I'll update when they arrive!
As always, the updated design is on GitHub: https://github.com/roscopeco/rosco_m68k/tree/master/design/r1
03/15/2020 at 22:17 •
I've spent a fair bit of time on the software for the board over the past week, and finally have a fairly nice serial boot loader working, meaning that software iteration is now much quicker as there's no need to pull the ROMs and reprogram for each test. This also means fewer dead ROM chips (I've got a small collection of failed chips that haven't survived the constant pull/program/reinsert loops).
This boot loader also handles initialisation of the rest of the system and provides a few TRAPs that can be used by loaded code. These are leveraged by a very simple proof-of-concept "kernel" that can be loaded by the boot loader and handles relocating itself from the initial bootload location, C linkage (with .bss initialisation etc) and provides the beginnings of a low-level library that interfaces with the machine via the aforementioned TRAP vectors.
As well as proving the boot loader works, this will serve as a useful base-project for code that can be loaded by the loader, and means I can really start working on the software for the computer now I'm free of the the 16KB limit imposed by the ROMs.
So with that, the PCB migration KiCad done and work started on the revision one board, it's been quite a busy week all round :)