04/27/2021 at 20:13 •
I've mentioned Xosera briefly before, but in case you missed it, Xosera is a fully open-source FPGA-based video adapter created by my good friend @Xark . In the words of the project's Github:
Inspired in concept by it's "namesake" the Commander X16's VERA, Xosera is an original open-source video adapter design, built with open-source tools, that is being tailored with features appropriate for a Motorola 68K era retro computer.
Until now, video on the rosco_m68k has been a slightly hit-and-miss affair, with the main video card being the V9958-based one I designed last year. This is a nice little card, and works well, but suffers a couple of fairly major problems:
- The V9958 is super-hard to get (at least if you care about getting genuine, working chips)
- The 15KHz RGB video output (via SCART) isn't great if you're in a part of the world where SCART isn't really a thing
- The V9958, while nice, is more suited to 8-bit-era machines. For rosco_m68k, I wanted something with a bit more power!
Xark's been working on Xosera since fairly early on in the rosco_m68k timeline, and things have really heated up a bit lately since we decided that Xosera should be the standard video for the next rosco_m68k machine. Based on that, I (finally) got it together and designed the m68k bus interface board I'd been promising for months, and from there Xark has been doing fantastic work, delivering major new features and improvements almost daily.
As well as having Xosera be the video on the next rosco_m68k, we also want to support the existing models too, so the first prototype bus board is designed as an expansion that works with all rosco_m68k models. It's in the prototype stages yet, so rather than having the FPGA and supporting hardware on-board, it accepts an Upduino 3.0 that plugs in and provides all the FPGA goodness. Likewise for the video interface - rather than hardwire for (e.g.) VGA a standard PMOD interface is used, allowing Xark free-reign during the prototyping and development stage - for example using HDMI rather than VGA for output.
The prototype board looks like this:
In true prototype style there's lot of extra jumpers and test points on there for us to use while debugging things, but the bring-up was pretty much effortless in the end. Aside from a minor issue (my fault) in which I got the POD pinout the wrong way around, it works great. Populated and hooked up (with PMOD on wires to correct for inverted pinout), it looks like this:
We're not quite at the graphics mode yet, but have a couple of very-capable (and fast, this thing comfortably runs zero-wait-state on a 12MHz 68020, even on fast tight fill loops running out of on-die cache) text modes. Here's a little "tech demo" snake game I threw together while playing with it (in 100% m68k assembly):
Here it is displaying something like 4096 colours at once (this time driven by Xark's AVR testbed, which he built while waiting for his prototype m68k PCB):
This is very cool as it uses the advanced auxiliary registers provided by Xosera to monitor beam position and do clever things at just the right time.
And finally, here's a short video from the "self-test" sequence Xark wrote for AVR, and which I ported to m68k (keeping it in C++ and building with the rosco_m68k GCC toolchain). This is running at 848x480 at 60Hz (via VGA).
Between Xosera and @MarkM's awesome work on IDE (that deserves its own log, which will be up soon!) things are moving fast over in rosco_m68k land. Be sure to like and follow the project for more, and for up-to-the-minute news come and join us on Discord.
03/17/2021 at 21:53 •
I'm just adding this log because it's the only way I can find to add pictures to the project. This is the special M68k 40th anniversary limited-edition board that we gave out as competition prizes last year :)
03/17/2021 at 21:30 •
I've posted before about how it's getting harder to find some of the vintage chips used in this project, and things aren't getting any better. I have a pretty good source for MC68010s at the moment (and have stock), but things like the MC68681 and V9958 are so hard to find that I've had to stop offering them as part of the kit on Tindie :(
With that in mind, there's been a lot of discussion recently over on Discord about future directions for the project, and the awesome community came up with some great ideas for the next major board version! Big thanks to everyone who's been involved in discussing this and suggesting ideas so far!
The Next Major Board Version
The new board won't replace the current one (in-fact, I've just sent of a new revision of the version 1 for manufacturing - more on that below!), but will be a kind of souped-up "pro" version - I'm thinking along the lines of A3000 vs A500 :)
Briefly, these are the specs we're working to at the moment:
- Modular CPU, supporting 68020 or 68030 (modular, on a daughterboard)
- Full 32-bit data and address bus on the mainboard
- The MC68901 will be replaced in UART duty by a MaxLinear XR68C681 (PLCC, but mounted in a THT socket)
- Expansion via an evolution of the current bus, with buffering and DIN 41612 connectors
- 2MB RAM as standard, expandable (probably with SIMMs of some kind)
- IDE on-board (thanks to MarkM on Discord)
- I2C on board (with a PCF8584T)
- Video on board ( with Xark's Xosera FPGA project)
- Sound - Possibly something on-board, as yet undecided
Obviously some of these components will be SMD, which is a shame as I've always wanted this project to be easily-solderable by those of all skill-levels, but I think for the "pro" version it's not such a big deal, and I'm planning to offer the kits with those few components pre-soldered.
In terms of design, it's very early days yet - I've barely broke ground in Kicad beyond setting up a new project and importing the relevant libraries, but I'll definitely keep updating here as things progress! And as always, all this is up for discussion, either in the comments here or on discord.
The Next r1 Revision
There's been a lot of work on the firmware lately, and the latest alpha firmware (v1.3) now has reasonably well-tested SD card support! In support of this I recently respun the r1.2 board with the addition of dedicated pins for an SD 5V adapter (like this one for example). There's also some bug fixes and general tidy up on there, making this the most reliable, most capable rosco_m68k ever. It will be launching on Tindie as soon as I get the boards back from the fab and check I've not made any silly mistakes :D
New 68681 board
Following on from discussions on the next major version, I decided to back port some of the future-proofing ideas back to the r1, starting with replacing the existing MC68681 DUART board with a XR68C681-based one. The prototypes are working perfectly, and I'm waiting on a good quantity coming back from the fab right now. It looks like this:
This will be supported out-of-the-box with the next firmware release later this week, and the board will launch on Tindie (with the option of getting new ROMs in the package) at the same time. This will allow me to once again offer full kits of the 68681, which I've not been able to do for a while because of a lack of original MC68681s of sufficient quality.
Lots more going on
There's lots going on with this project, and this post only just scratches the surface! There's all kinds of community hardware projects in the works, from a "super IO" board that e2k is working on to Henk's flat-out-awesome front panel, and there's a ton of software happening too. I'll definitely try to be better about updating here but if you want to stay in the loop, join us over on Discord!
11/22/2020 at 20:34 •
A while ago I bought some MC68020RC12s, and I recently decided it was time to do something with them, so I made a little adapter that allows the 020 to plug into the 64-pin DIL socket used by the MC68010 on the rosco_m68k. Of course this limits the 020 to 24-bit addressing and 16-bit data, but seemed a fun project and a good way to get started with integrating the 020 in preparation for the future.
The idea is basically to connect up the 020 to the mainboard bus, plus allow it to have it's own clock. There's a little bit of glue logic translation done by an ATF16V8BQL on the board. The layout looks like this:
The design isn't ready for prime-time yet, but I had a few prototypes made, and it works perfectly on the revision 1 board. There's an issue with DTACK generation on the revision 1.2 (which isn't new, we've known about it for a while but I've put off fixing it as it was "good enough" - until now).
When plugged into the main board (with some spacers on the headers going into the CPU socket to give some vertical separation from the RAM/ROM chips) it looks like this:
Even with the 16-bit bus (and with a relatively-slow 12MHz 020), this is already showing an impressive turn of speed in benchmarks. The 10MHz 010 dhrystone results were:
rosco_m68k 68010-10Mhz ROM gcc-7.5.0 - 1086 (-O1)
rosco_m68k 68010-10Mhz ROM gcc-7.5.0 - 1086 (-O1)
While the 020 gives:
rosco_m68k 68020-12Mhz ROM gcc-7.5.0 - 2604 (-O1) rosco_m68k 68020-12Mhz ROM gcc-10.2.0 - 2860 (-O1) rosco_m68k 68020-12Mhz ROM gcc-10.2.0 - 2941 (-O1 -mtune=68020)
(The score is the figure in the right column, for a fair comparison both GCC 7.5.0 (which we were using at the time we last benchmarked the 010) and the current GCC 10.2.0 have been tested.
As usual, the design files, PLD code and gerbers can be found in the hardware projects repository in GitHub: https://github.com/rosco-m68k/hardware-projects/tree/master/r1_020_expansion
10/11/2020 at 02:44 •
Wow, it's been three months since I last updated here, but that's not because nothing's been happening with the project - in fact, exactly the opposite! I've been so busy improving things and keeping up with the awesome stuff the community are doing that I've just not had time to write a log for a while!
For this log I'll just do a quick update on what's been happening over the past couple of months, with a promise to get better at keeping things up to date here on HaD.
Something that's always been a sticking-point for me (and for quite a few others now) is the 9600 BPS speed limit on the built-in MC68901 UART. As a step toward addressing this, I designed a whole-new comms board for the rosco_m68k, based around the (very capable!) MC68681. This brings two independent UART channels, the potential for future expansion with some additional IO ports, and makes uploading code to the system much less painful thanks to it's reliable support for baud rates up to 115.2Kbps.
Even better, this is a drop-in replacement for the MFP UART, with recent revision 1.2 ROM builds supporting it out of the box (with auto detection). The board itself looks like this:
I talked a bit about the design in a previous log, but at that point the board wasn't generally available, and the code for it was nowhere near complete (beyond a breadboard design and a basic demo). That's all changed, and it's now available on Tindie :)
SPI & LCD Awesomeness
There's been a lot of development lately around getting bit-banged SPI working, using the GPIOs provided by the MC68901, and @Xark changed the game by implementing some new SPI routines that were >5x as fast as the ones we had before. Not content with that, he went on to use his new SPI routines to implement an awesome bit-banged SPI LCD slide-show for the rosco_m68k!
The code itself is awesome, but the video shows it even better:
That's right - this is a 16/32-bit m68k system pushing full-colour images out over SPI via the (almost forty-year-old) MC68901, all driven by some super-optimised hand-crafted assembly SPI routines. Totally awesome!
(In other news, Xark also became the first committer on the project who isn't me, and has already made some great contributions!)
SD Card Support
Hot on the heels of Xark's SPI stuff, we were able to revisit the SD Card support, specifically using the faster SPI routines to get a decent speed boost.
It's early days yet (the code is still sitting in a PR but will likely be merged by the time you read this) but it's looking pretty good - SD support is in the development ROMs, with an SD loader, pretty-complete FAT support (thanks to ultraembedded's FAT library) and support for SD filesystems in user code via a new standard library.
There's been so much more going on that I haven't mentioned here - expect an upcoming post about a totally awesome front-panel project, a brand-new but very promising OS, and tons of other stuff. And this time, I promise it won't be three months before I do those posts!
07/08/2020 at 21:56 •
Now that the V9958 video board is shipping on Tindie, and I've gotten fresh stock of all the options for the base board, I've been working on getting a basic text mode console supported by the standard firmware. It took me a while to get used to the way the V9958 works, but thanks to the pretty great Yamaha documentation that's still available online (link for V9938, the V9958 documentation just lists the changes) it wasn't too difficult to make something work.
Here's a shot of it running Jeff Tranter's adventure, with the unmodified code that runs on the board without video connected.
(Sadly I don't currently have a CRT to run it on, but I'm working on that!)
Getting this working in the firmware in a way that was compatible with the current revision 1 board presented two challenges - firstly, I had to write the code for the console, including taking care of scrolling and tracking cursor position etc, and secondly I had to somehow find a way to get the code to fit in the severely-limited 16KB of ROM (a good chunk of which is taken up by the Kermit routines already).---------- more ----------
The first challenge was writing the code. I'd already done some examples and proof-of-concept / demo code for the V9958, including a naive text-mode console demo that basically redrew the whole screen during the vertical blanking interval.
While this worked, it made the VBLANK take so long that there wasn't time for the computer to do anything else! Obviously it was fine as a demo (and let me figure out the basics of the V9958's TEXT2 mode) but for something general purpose that would go into the firmware a better way was needed.
The result of this work was the second text-mode console demo, which is much more efficient, and has a VBLANK that runs in a timely fashion. The general approach here is:
- Have an in-RAM circular buffer with the current screen contents
- Have two pages in video RAM, one of which is always current
- When printing a character, it goes directly to the active VRAM page for display, as well as the RAM buffer
With this scheme, the VBLANK handler usually does nothing much (except handle the blinking cursor). When the time comes to scroll the screen, non-interrupt code does the following:
- Increments the RAM buffer start pointer by a line length, and clears the last line
- Copies the RAM buffer to the non-active VRAM page
- Sets a dirty flag
With that done, next time there's a VBLANK, the handler just flips the pages (by setting the appropriate V9958 register with the new active page start), which again takes very little time.
Obviously it's slightly more involved (handling backspace characters and so on) but that's the basic gist of it, and I have to say I'm pretty happy with it. It works really well, scrolls nicely with no visual tearing or other artefacts, and means that there's never a long-running interrupt handler starving the rest of the system. The use of two VRAM pages means you never see a half-scrolled screen.
I did play around with using the V9958s blitter commands (which are available in text modes, unlike on the 9938) but the timing was a nightmare, and the fact that the commands haven't really been updated (and so one has to translate coordinates to their graphics mode equivalents, for example) made it not worth the effort. I may yet revisit this in the future, but as I say, it works and I'm happy with how it turned out.
The next challenge was making it fit in the ROMs. The 16KB ROMs I (short-sightedly) used for the revision one boards were already pretty full, and I definitely didn't want to lose any of the existing functionality - the idea here is to make a new minor revision of the firmware that is a drop in replacement, but also detects and uses the V9958 if fitted.
I played around with a few different ideas, and eventually settled on splitting the firmware into two stages - stage one would handle the basic machine initialisation (including the V9958) and provide the resident ROM code and TRAP handlers (both TRAP 14 which is rosco_m68k basic IO and TRAP 15 which provides Easy68k compatibility). Stage two would take care of loading user programs (via Kermit at the moment, though with this split it can be easily replaced with code to load via SD card, for example, which we're already working towards).
How does this save any ROM space? That's the clever bit - stage 2 is compressed (with a simple Zip-based algorithm). Once the basic machine is initialised, stage one unzips stage two into RAM, and runs it from there.
The Zip algorithm doesn't give super high compression ratios, and is optimised for size in the decompression code (otherwise the advantage of using compression would be lost), but it's good enough to fit everything that was previously in the firmware, plus the V9958 code and a text-mode font (which currently isn't, but could easily be, compressed too - at the moment it just lives alongside the V9958 code itself, which has to be in stage one so it's always available in ROM).
There's still some scope for saving a few bytes (which I'm hoping to use to provide a similar "pluggable" interface for the UART, to allow it to auto-detect the coming-soon MC68681 expansion board) but overall it works quite nicely, and is available in the current development branch for the new firmware (I'll try to remember to update here once it's actually released!)
06/13/2020 at 19:41 •
Over on Discord, @Xark recently did some work on porting some old dhrystones to the rosco_m68k, which gave a feel for the performance of the board for the first time, and the results are encouraging! In Xark's words, we "blew the doors off an outdated Dhrystone text file found somewhere on the Internet" :D
Obviously these are to be taken with a hefty grain of salt as they're hardly "fair" - we're using a much more modern compiler than was likely available for any of the other machines on the list, and we also don't have an OS to get in the way. To try and make it a more even fight we did limit the GCC optimisation to -O1, which feels like it should be roughly on-par with the optimisations that would have been done by the compilers in use at the the time the other machines were benchmarked.
To see how the rosco_m68k stacked up against other machines of the same era, we ran the benchmarks with both 8MHz and 10MHz system clock. The results were thus (further down the list is better):
Last updated 06/06/2020 by Xark *----------------DHRYSTONE VERSION 1.1 RESULTS BEGIN-------------------------- * * MACHINE MICROPROCESSOR OPERATING COMPILER DHRYSTONES/SEC. * TYPE SYSTEM NO REG REGS * -------------------------- ------------ ----------- --------------- * Apple IIe 65C02-1.02Mhz DOS 3.3 Aztec CII v1.05i 37 37 * - Z80-2.5Mhz CPM-80 v2.2 Aztec CII v1.05g 91 91 * - 8086-8Mhz RMX86 V6 Intel C-86 V2.0 197 203LM?? * IBM PC/XT 8088-4.77Mhz COHERENT 2.3.43 Mark Wiiliams 259 275 * - 8086-8Mhz RMX86 V6 Intel C-86 V2.0 287 304 ?? * Fortune 32:16 68000-6Mhz V7+sys3+4.1BSD cc 360 346 * PDP-11/34A w/FP-11C UNIX V7m cc 406 449 * Macintosh512 68000-7.7Mhz Mac ROM O/S DeSmet(C ware) 625 625 * VAX-11/750 w/FPA UNIX 4.2BSD cc 831 852 * rosco_m68k 68010-8.0Mhz ROM gcc-7.5.0 - 862 (-O1) * DataMedia 932 68000-10Mhz UNIX sysV cc 837 888 * Plexus P35 68000-12.5Mhz UNIX sysIII cc 835 894 * ATT PC7300 68010-10Mhz UNIX 5.0.3 cc 973 1034 * rosco_m68k 68010-10Mhz ROM gcc-7.5.0 - 1086 (-O1) * Compaq II 80286-8Mhz MSDOS 3.1 MS C 3.0 1086 1140 LM * IBM PC/AT 80286-7.5Mhz Venix/286 SVR2 cc 1159 1254 *15 * Compaq II 80286-8Mhz MSDOS 3.1 MS C 3.0 1190 1282 MM * MicroVAX II - Mach/4.3 cc 1361 1385 * DEC uVAX II - Ultrix-32m v1.1 cc 1385 1399 * Compaq II 80286-8Mhz MSDOS 3.1 MS C 3.0 1351 1428 * VAX 11/780 - UNIX 4.2BSD cc 1417 1441 * VAX-780/MA780 Mach/4.3 cc 1428 1470 * VAX 11/780 - UNIX 5.0.1 cc 22.214.171.124 1650 1640 * Ridge 32C V1 - ROS 3.3 Ridge C (older) 1628 1695 * Gould PN6005 - UTX 1.1c+ (4.2) cc 1732 1884 * Gould PN9080 custom ECL UTX-32 1.1C cc 4745 4992 * VAX-784 - Mach/4.3 cc 5263 5555 &4 * VAX 8600 - 4.3 BSD cc 6329 6423 * Amdahl 5860 - UTS sysV cc 1.22 28735 28846 * IBM3090/200 - ? ? 31250 31250 *
It was really exciting to see these results - the rosco_m68k is the fastest 68000 in both the 8MHz and 10MHz categories :)
I will say again that the lack of an OS at the moment is probably a distinct advantage here, although these results were captured with the system timer tick running which does some memory access a couple hundred times a second and toggles a GPIO periodically, so it's not like there was nothing else going on - I like to think the results are in some way representative.
You can find the code along with the results in a text file here.
06/07/2020 at 18:56 •
One of the things that's become an increasing problem on this project is the MC68901 Multi Function Peripheral. Way back when I started this project (actually when I ordered the very first MC68010 for it!) I ordered a 68901, almost on a whim, as it seemed like a very capable chip that would take care of a lot of problems for me. To an extent that turned out to be true, but the venerable MFP brings with it more than its fair-share of problems too.---------- more ----------
The MFP was introduced sometime around 1983/84 and was one of the earlier 68000-specific peripherals, replacing a bunch of earlier 6800 legacy peripherals. On paper, it's a great chip - it sports a vectored interrupt controller, programmable timers, interrupt-capable GPIO with various trigger modes, and a USART. The fact that it packs so much into a small (48 pin DIL) package was one of the things that attracted me to it.
Unfortunately, although it does a lot of different stuff, it's very much a "Jack of all trades, master of none" - it doesn't really excel at any of the various tasks. As an interrupt controller it's okay, and the programmable timers are quite useful (especially if you have need to use the advanced event counting and PWM modes). The GPIOs are okay for certain tasks, but not fast enough for, for example, bit-banging SPI (I think we measured them flat-out under software control at around 133KHz). And that's fine, because that's not what they're designed for. For interfacing legacy (read 6800) peripherals into the vectored interrupt scheme they're pretty great.
The UART (well, USART) is what really lets the 68901 down. Specifically, it's slow. This is largely due to the fact that it is totally useless unless used with the divide-by-16 baud rate clock, and when that clock is generated by the MFP itself (the recommended configuration from a Motorola application note) there's an additional divide-by-four pre-scaler. Coupled with the (necessary) divide by 16 this limits the baud rate that's usable to 9600 (if one cares about using POSIX rates, 28800 is possible otherwise but not supported by some of the support software).
As an aside, you could in theory drive the BRG from an external clock, and avoid the divide-by-16 counter, but of course this ups the component count and requires another clock (rather than just a crystal). The maximum one can use is 4MHz so a standard 3.6864MHz clock could be supplied and who knows, it might work well at higher speeds. Speed isn't quite the whole story though.
Programming the UART on the MFP in an interrupt-driven scheme is also fraught with problems. It boils down to the fact that, because of the way the registers are designed, there's no good way (that I've found at least) to safely implement a transmit ring buffer without risking deadlock. Because of the way pending interrupts are handled, you cannot be assured that a pending "buffer empty" interrupt that occurs while the interrupt is disabled will actually be raised once they are re-enabled. This leads to an awkward two-step dance of fully disabling the transmitter while trying to work out if the character to be sent should be buffered or just sent directly to the transmit buffer.
To make things worse, the buffer on both transmit and receive are only a single byte in size, and the slow GPIO (coupled with the pretty lax interpretation of CTS by the FTDI chips) means that "hardware" flow control (under software control - the MFP doesn't provide any help with this) is pretty much useless.
So to cut a long story short(er), I've been getting pretty frustrated with this, both from the UART perspective and also from the point of view of wanting to get SD cards and other SPI devices working. With this in mind, I started looking into the MC68681 DUART.
The 68681 is a slightly newer chip than the 68901 (arriving in late 1985), and was likely designed by some of the same people. In fact, when reading the data sheet and working with the chip, it definitely appears that some of the design choices came about as a direct result of lessons learned from the 68901. As you'd expect, it fully supports the 68k asynchronous bus architecture, and can do vectored interrupts.
It's a very capable chip: two completely separate UARTs, parallel input and output ports (6 and 8 bits, respectively) and full hardware flow control. I received a bunch of 'em last week and got straight to work on the integration. And of course, it works perfectly. I've now got a (proof of concept, at this point) working Kermit upload at 115,200 BPS (quite a jump from 9600!)
The current design looks like this (initially this is going be an expansion for the rosco):
Unfortunately, the shadow of the 68901 is long, and this is still hampered by some of the decisions I made when initially integrating the MFP. This can't use vectored interrupts at the moment, because the MFP greedily takes all of odd IO space. Vectored interrupts require a vector on the low-order data lines, and that's just not possible yet. So for now this will use auto vectoring (one of the GALs takes care of the VPA line for this). DTACK is another area where the MFP over-steps it's boundaries (due to my design though, not the chip itself), hence the jumper on the DTACK line - the point of that is to make sure this expansion is compatible with both current and future iterations of the main system design.
In terms of code, the initial testing for this has been great. Once I'd spent a little while with the data sheet getting to know the chip getting it to 57K6 was fairly easy using its ability to directly use it's own built-in timers to generate a baud clock from an external 3.6864MHz crystal. The final step to 115K2 was a little less obvious, but googling around I found the answer - one simply has to enable "test" features of the IC, but reading from a register the data sheet explicitly says not to read from! This appears to be a common thing, and seems to work fine. I'm keeping the option of dropping back to 57K6 in my pocket though, just in case...
This is the basic initialisation code, plus polled send and receive. Interrupt driven is next on the list to implement.
INIT_SERIAL_HANDLERS:: move.b #$0,DUART_IMR ; Mask all interrupts move.b #$93,DUART_MR1A ; (Rx RTS, RxRDY, Char, No parity, 8 bits) move.b #$07,DUART_MR2A ; (Normal, No TX CTS/RTS, 1 stop bit) move.b #$60,DUART_ACR ; Set 0, Counter, X1/X2, /16 move.b DUART_CRA,D0 ; Enable undocumented rates move.b #$66,DUART_CSRA ; 1200 per spec, uses counter instead move.b #0,DUART_CUR ; Counter high: 0 move.b #2,DUART_CLR ; Counter low: 2 (115.2KHz) move.b R_STARTCNTCMD,D0 ; Start count ; Debug - output clocks on OP2 for scope ; move.b #%00000011,DUART_OPCR ; RxCA (1x) on OP2 move.b #%00000101,DUART_CRA ; Enable TX/RX ; TODO CTS/RTS Not yet working - figure out how to lower RTS! move.b #$ff,W_OPR_RESETCMD ; Clear all OP bits (lower RTS) move.b #0,W_OPR_SETCMD rts RECVCHAR:: btst.b #0,DUART_SRA beq.s RECVCHAR move.b DUART_RBA,D0 rts SENDCHAR:: btst.b #3,DUART_SRA beq.s SENDCHAR move.b 7(A7),D0 move.b D0,DUART_TBA rts
06/04/2020 at 22:45 •
Development on the V9958 board continues apace, and after a false start due to a silly mistake in the first revision things are back on-track with a revision 1 prototype. The design is now validated and working really well. So far it's baby-steps in terms of software, with just enough to show an image.
That's the board image from the website, scaled to a suitable size for the V9958 and reduced to 256 colours. It's bundled in with the code that sets up the VDP and copies the data into video RAM (64KB populated in this image, just enough for testing). Output is RGB via SCART, using a six-pin DIN connector which is compatible with readily-available cables designed for BBC Micro and Acorn computers :)
(Aside: There's also a header on-board with RGB and sync signals that will be compatible with things like http://www.jrok.com/hardware/RGB.html for those in non-SCART countries, and I plan to do a small daughterboard based on some CXA1645s I have lying around that will fit that header too).
Address decoding and selects for the VDP are handled by a couple of 16V8s, and the decoding is specific to the address range needed by the four ports the VDP exposes. I was keen not to repeat the short-sighted mistakes made earlier (with the MC68901 for example, which greedily takes all of odd IO space), and going forward will be doing the same with all the expansions. The next main board revision will also fix the underlying issue with the MFP decoding too.
Programming the V9958 is actually quite a nice experience. I've not done any real "in-anger" work with it yet, but what I have done has been pleasant. Its register set-up isn't especially arduous, and it has some nice features like auto-increment for both VRAM address and register number that make things nice and manageable. The documentation is pretty great too, though it's a bit unfortunate that one has to consult the original 9938 documentation in conjunction with the changes listed for the 9958 in a separate document. I suppose when these documents were current they would have been actually printed on real-life paper, so it makes sense that there wasn't a completely new document for the (relatively few) changes between the 9938 and the 9958.
I did run into a slightly odd issue that took a little bit of debugging (here, MAME once again proved worth it's weight in gold) - it turns out that the V9958 is a little bit picky about the order of things during initialisation, and this isn't totally obvious from the manual. Being able to single-step things and view memory in MAME was invaluable.
In the end, the code to display the image above is quite compact. This is the meat of it, including complete set-up of the VDP, switching to G7 mode, and copying the data to video RAM (the 'SLOWDOWN' subroutine referenced below is simply three NOPs and an RTS):
; Set mode G7, disable interrupts and enable output move.b #%00001110,PORT_WREG_SETUP ; Write DG=0,IE2=0,IE1=0,M5=1,M4=1,M3=1 move.b #$80,PORT_WREG_SETUP ; To register 0 move.b #%01000000,PORT_WREG_SETUP ; Write BL=1,IE0=0,M1=0,M2=0,SI=0,MAG=0 move.b #$81,PORT_WREG_SETUP ; To register 1 ; Set PAL mode move.b #%10000010,PORT_WREG_SETUP ; Set 212-line, PAL mode... move.b #$89,PORT_WREG_SETUP ; .. to register 9 move.b #%00000000,PORT_WREG_SETUP ; Select BG: GGGRRRBB move.b #$87,PORT_WREG_SETUP ; .. In VDP register 7 move.b #%00001010,PORT_WREG_SETUP ; Select 64K DRAM, disable sprites move.b #$88,PORT_WREG_SETUP ; .. In VDP register 8 ; Set pattern layout table to 0x0 move.b #%00011111,PORT_WREG_SETUP ; bit 16 of 0x0, constant 11111 move.b #$82,PORT_WREG_SETUP ; .. to register 2 ; Set up to write VRAM at 0x0 move.b #0,PORT_WREG_SETUP ; VRAM Base at 0 move.b #$8E,PORT_WREG_SETUP ; > register 14 move.b #0,PORT_WREG_SETUP ; Set VRAM A0-A7 move.b #$40,PORT_WREG_SETUP ; Set VRAM A8-A13, and write enable move.l #_image_start,A0 move.l #_image_size,D0 bra.s .COPYSTART .COPYLOOP: move.b (A0)+,PORT_RWDATA bsr.s SLOWDOWN .COPYSTART dbra.w D0,.COPYLOOP move.l #$10000,D0 subi.w #_image_size,D0 bra.s .CLEARSTART .CLEARLOOP: move.b #0,PORT_RWDATA bsr.s SLOWDOWN .CLEARSTART: dbra.w D0,.CLEARLOOP
I'm really looking forward to doing more with this, and can't wait to actually get some redrawing going on in the vertical retrace.
There's a couple of tweaks to make to the board for added buildability and stability, and then it'll go off for manufacturing. I'm hoping to launch it on Tindie in a few weeks time.
In the meantime, as well as video software, I'm also making a start on fixing the slow UART that has been a problem for a while. The 68901 was a great chip to get started with, and still has its uses, but we've outgrown its UART. I have a bunch of MC68681s, and the time has come to use them! More about that in a future log :)
05/30/2020 at 19:13 •
There's so much going on with the rosco_m68k at the moment, it's hard to keep up! Not just the stuff that I'm planning (of which there is lots!) - it's really exciting to see what the growing community are doing too. There's always a ton of conversation going on over on the discord server, with new and cool projects (both software and hardware) being worked on.
In no particular order, we've got a floppy-drive controller @henk.gooijen is planning (to go alongside the absolutely awesome monitor software / firmware he's created - screenshot below), a real-time-clock integration thanks to @RTS4E75 (and an IDE interface in the works). Some people are even working on some amazing FPGA stuff that's totally beyond me at this point - @Claude is working on interfacing the M68k bus to an ice40up5k (on a upduino 2.0) and @Xark has made some amazing progress on his VGA video card. I'm not going to talk too much about that as I don't want to spoil the surprise, Xark tells me he's planning to write up a Hackaday project about it, so keep an eye out for that - it's exciting stuff (we've already seen some amazing output from it on a VGA monitor!).
As I've said before it's pretty humbling that people are finding so many cool things to do with this little project that started out on breadboard as a "I wonder if I can do that" thing about 18 months ago. I love that people are picking this up and running with it, and having so much fun :)
Of course, the community is great for finding things that could be improved, and there's a whole bunch of things that have already been earmarked for a future board revision. Everything from better bus connectors to tighter IO Space decoding and bigger ROM is in the works, and as well as the V9958 video I talked about in the last log I'm also working on sound (YM2149F) and some firmware/software improvements.
I've also ordered a bunch of ICs today for various expansions I'm planning - including some much-needed MC68681 DUARTs and *lots* of 7400 series bus transceivers, some 22V8 GALs and various other support chips. Things have taken off so quickly that I've not had as much time as usual for hardware lately - I'm really looking forward to diving back in!
If you want to get involved, or even if you just want one to play with (we now have a bunch of precompiled example programs, including a BASIC interpreter!) I've just received fresh stocks, so grab yours on Tindie.
As promised, here's a screenshot of Henk's frankly awesome monitor. Keep your eyes peeled for an upcoming post from Xark in which he tells me he'll be showing some really cool pics too :)