68K (no Mac) Designs OK?

[Gorgonops]

Yeah, I think the 68000 and Z80's (for sound) are some of the most popular arcade processors from the 80's/90's.

I'm kind of surprised in retrospect that it doesn't seem like Sega explicitly pointed that out in their advertising for the Genesis, as it's also a dual 68000/Z-80 architecture. (Of course, it's also interesting that Sega marketed the Genesis as a "16-bit" system while most of the computer makers using the 68000 heavily emphasized the 32-bit attributes of its ISA.)

 

[cbmeeks]

Sega should have done what Atari did and just add up all the bits.  The 68K with it's 32-bit registers plus the 16-bit address bus of the Z80.  So the Genesis is a 48-bit system.   LMAO.

At least they had Blast Processing.

 

[olePigeon]

Yeah, I think the 68000 and Z80's (for sound) are some of the most popular arcade processors from the 80's/90's.

Don't forget the Texas Instruments LPC speech chips.   Used extensively not in just arcades, but also on home computers like the Apple II.  Probably most famous for the Speak & Spell.

 

[techknight]

I am curious about this thread, because I would like to know how to compile C/C++ programs for a 68K single board computer that is NOT a Mac. I was looking at Retro68K, but I think its setup to target the Mac arch, no?

I was looking at BMOW uCLinux option, but he made a ton of modifications in the kernel/BSP and not really any good comments on why or what they do. (Not familiar with a linux kernel, or 68K ASM). 

I have been buried head deep in a project since December that is baseed on the MC68010, it has Two of them, its a VMEBus system with multiple cards.

I have been in the process of reverse engineering the system back into schematics for trying to re-create the software to allow this unit to function again. Since the original software was downloaded over satellite and is long long gone. 

it does have a Ready Systems RTOS Kernel in ROM, but again since I am not that fluent in 68K, or even worse, C compiled 68K that abuses the stack, I cant make heads or tails of it. So rebuilding something equivalent is necessary. 

 

[Crutch]

What do you want the code to do? If you just want it to access memory and do calculations and leave a result in memory somewhere, any ordinary Mac 68k code complier should work fine for that purpose - either retro68k or even THINK C on a legacy platform. With THINK C you could even embed asm{...} blocks and leave your result in a register. Just compile your code into a Mac application and use ResEdit to extract the hex dump of CODE resource 0. That’s your compiled 68k code that should run on any 68k platform. You could compile a function this way also, since the argument passing mechanics should be the same. Obviously if you call any Mac traps they won’t work, and you want to make any system calls onto your target platform you’d have to do from an asm block and wouldn’t be able to test on the Mac emulator.  (Basically this is probably only a helpful answer if you’re trying to do something quite simple, which I’m guessing you’re not...)

 

[techknight]

I have to write code that receives data from a data card, I have to write code to speak to another 68K on the bus to render graphics, and then I have to write code that runs on the other 68K CPU that actually renders the graphics, and enters into DMA transfers across the VMEBus to grab the graphics to be displayed from shared asset RAM. The graphics card has its own CPU basically acting as a GPU, but again it downloads its program from the main CPU card when its up and running. 

What I am saying is, there is no OS. so the application has to do everything. Including building and setup of the Vector table in RAM, as well as the Trap handlers for all I/O operations. Including that of reading the RTC IC. (so I have to write a driver for that). 

As well as a Vertical Blanking interrupt handler for doing things like on-screen Roll, and Crawl, as well as keeping software timers. 

So no, its not so simple. But my main question was is there a modernish C/C++ compiler that will build stand-alone drivers/vectors/applications for a 68K that isnt attached to the macintosh specific ROM, etc... 

Also there is no "system calls" or anything of that nature. its basically lights and clock-work with no code. So I have to write the code to make it run again. 

Basically, Bare-Metal programming. There is no ROM code (well there is, but no API/Documentation on how to use the built-in kernel, and the guy who wrote it is dead, so it must be replaced)

Basically, write a program, function, subroutine, etc. that compiles into an organized BIN file that I can either load and execute into RAM from a bootloader, or Burn into PROM and the 68K will boot and run it.

 

[Gorgonops]

It should be fairly straightforward to cross compile using GCC, is there a reason you don't want to go with that?

 

[techknight]

No, not really. GCC would be ideal if it works the way I am imagining it would. 

Just not familiar with GCC. when I was looking up Retro68K compiler, it was all mac-based so I didnt know if it could compile straight binary that isnt "mac".

I almost need a "hello world" example or something. Maybe there is one out there already. 

 

[commodorejohn]

There's also VBCC, which is modern-ish (full C89 with a subset of C99 features supported,) specifically targets 68k/Coldfire, and supposed to produce overall better code than GCC according to what I've heard.

 

[Gorgonops]

and supposed to produce overall better code than GCC according to what I've heard.

A quick summary of googling around forum discussions seems to indicate that it might produce better code than GCC 2.9, but 2.9 was a long, long time ago.

I almost need a "hello world" example or something. Maybe there is one out there already. 

There are definitely examples floating around for doing cross-development targeting bare metal with GCC. Here's a brief one, but there are whole books on it:

https://jefftranter.blogspot.com/2017/05/building-68000-single-board-computer-c.html

(EDIT: If you go to that link, click on the "68000" tag for more useful posts. One in particular that would probably be of interest is one which talks in brief about the newlib C library targeted at minimal, small-memory platforms like a homebrew board. You'll need some kind of C library, or at least badly want one, once you get anywhere beyond the "I've initialized the hardware and made the lights blink" level of bringing up the system.)

 

[techknight]

Thanks for the advice, Yea going forward I will need a standard C library. Appears from research that it requires a board support package at minimum, Which of course it will need since it isnt gonna know what bus it has, where everything is, how to initialize everything, etc. So, I am thinking I almost need a skeleton of a BSP package.