8bit-Unity version 0.3.5
8bit-Unity version 0.3.5
It's been a while since I posted any info relating to 8bit-Unity on this forum, so with version 0.3.5 coming out in Novembre 2020 I wanted to give a recap of functionality added over the past 18 months.
Since version 0.3.0, these 5 platforms are supported: Apple//, Atari 8bit, C64, Oric1/Atmos, and Atari Lynx (plan to add support for the 7800, 5200, NES and BCC (all 6502 based)).
The SDK code is modular (to save on memory footprint), with libraries for multi-color graphics (9 colors on Atari 8 bit), sprites handling, music playback, GUI widgets, on-screen animation, and so on. Best of all, the asset pipeline is streamlined so that the same tools are used to create bitmap/sprites for all platforms.
The SDK includes a good number of Tech-Demos, with code re-usable in other projects:
- Demo Disc (showing usage of every module)
- 8bit-Slicks: Top-down racer (full-game)
- 8bit-Grubs: Simple artillery (demo game)
- 8Bit-Goblin: Point-n-Click adventure (demo game)
- 8bit-OS: App based graphical os, using widget system.
Finally, the 8bit-Unity SDK is compatible with a nice little piece of hardware called the 8bit-Hub, which I developped specially to provide Wifi, SD storage, Mouse (and in future co-processing) to the supported platforms.
I hope this information is useful to people interested in developping multi-platform games/apps. For my part, I will keep developping this project in coming years to add more features and more target platforms!
(If you are still reading this, then head out to 8bit-unity.com to download the latest version!)
Since version 0.3.0, these 5 platforms are supported: Apple//, Atari 8bit, C64, Oric1/Atmos, and Atari Lynx (plan to add support for the 7800, 5200, NES and BCC (all 6502 based)).
The SDK code is modular (to save on memory footprint), with libraries for multi-color graphics (9 colors on Atari 8 bit), sprites handling, music playback, GUI widgets, on-screen animation, and so on. Best of all, the asset pipeline is streamlined so that the same tools are used to create bitmap/sprites for all platforms.
The SDK includes a good number of Tech-Demos, with code re-usable in other projects:
- Demo Disc (showing usage of every module)
- 8bit-Slicks: Top-down racer (full-game)
- 8bit-Grubs: Simple artillery (demo game)
- 8Bit-Goblin: Point-n-Click adventure (demo game)
- 8bit-OS: App based graphical os, using widget system.
Finally, the 8bit-Unity SDK is compatible with a nice little piece of hardware called the 8bit-Hub, which I developped specially to provide Wifi, SD storage, Mouse (and in future co-processing) to the supported platforms.
I hope this information is useful to people interested in developping multi-platform games/apps. For my part, I will keep developping this project in coming years to add more features and more target platforms!
(If you are still reading this, then head out to 8bit-unity.com to download the latest version!)
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: 8bit-Unity version 0.3.5
Looks great!
Question on the 8 bit hub though: is the joystick and network connectivity and SD card also usable without the SDK?
For example in own BASIC? And are the joysticks usable in existing games?
Question on the 8 bit hub though: is the joystick and network connectivity and SD card also usable without the SDK?
For example in own BASIC? And are the joysticks usable in existing games?
Re: 8bit-Unity version 0.3.5
Regarding Joysticks, I have alread tested a mode in which the Hub works as a PASE interface.
I will include it in future firmware update.
The communication code is quite simple, and could easily be implemented in BASIC using a dataset.
The sequence in C is as follows:
I will include it in future firmware update.
The communication code is quite simple, and could easily be implemented in BASIC using a dataset.
The sequence in C is as follows:
Code: Select all
// HUB Status Flags
#define COM_ERR_OK 0
#define COM_ERR_OFFLINE 1
#define COM_ERR_HEADER 2
#define COM_ERR_TRUNCAT 3
#define COM_ERR_CORRUPT 4
// HUB Commands
#define HUB_SYS_ERROR 0
#define HUB_SYS_RESET 1
#define HUB_SYS_IP 5
#define HUB_DIR_LS 10
#define HUB_DIR_MK 11
#define HUB_DIR_RM 12
#define HUB_DIR_CD 13
#define HUB_FILE_OPEN 21
#define HUB_FILE_SEEK 22
#define HUB_FILE_READ 23
#define HUB_FILE_WRITE 24
#define HUB_FILE_CLOSE 25
#define HUB_UDP_OPEN 30
#define HUB_UDP_RECV 31
#define HUB_UDP_SEND 32
#define HUB_UDP_CLOSE 33
#define HUB_UDP_SLOT 34
#define HUB_TCP_OPEN 40
#define HUB_TCP_RECV 41
#define HUB_TCP_SEND 42
#define HUB_TCP_CLOSE 43
#define HUB_TCP_SLOT 44
#define HUB_WEB_OPEN 50
#define HUB_WEB_RECV 51
#define HUB_WEB_HEADER 52
#define HUB_WEB_BODY 53
#define HUB_WEB_SEND 54
#define HUB_WEB_CLOSE 55
#define HUB_URL_GET 60
#define HUB_URL_READ 61
unsigned char hubState[7] = { COM_ERR_OFFLINE, 255, 255, 255, 255, 80, 100 }; // Error Code, Joy#1, Joy#2, Joy#3, Joy4, MouseX, MouseY
unsigned char sendID = 0, sendLen = 0, sendHub[256]; // Send data (e.g. UDP/TCP packet, URL...)
unsigned char recvID = 0, recvLen = 0, recvHub[256]; // Received data (back from server)
unsigned char packetID = 0; // Counter that keeps track of packets (so that corrupted packets are re-sent)
void SendByte(unsigned char value) {
// Send 1 byte to HUB
unsigned char tick;
POKE(0x0301, value); // Write to Printer Port
POKE(0x0300, 175); // Send STROBE (falling signal)
tick++; tick++; tick++; // Wait 3 cycles
POKE(0x0300, 255); // Reset STROBE
}
unsigned char RecvByte(unsigned char* value) {
// Recv 1 byte from HUB
unsigned char i = 255;
while (1) { // Countdown i to 0
if (PEEK(0x030d)&2) { *value = PEEK(0x0301); break; } // Look for ACKNOW on CA1 then read Printer Port
if (!i--) return 0;
}
return 1;
}
void SendPacket() {
unsigned char i, checksum, packetLen;
// Send Header
SendByte(170);
// Send Packet ID
if (sendLen) { sendID = sendHub[0]; }
checksum = (recvID & 0xf0) + sendID;
SendByte(checksum);
// Send Packet Data (if any)
if (sendLen) {
packetLen = sendHub[1];
SendByte(packetLen);
for (i=2; i<packetLen+2; i++) {
SendByte(sendHub[i]);
checksum += sendHub[i];
}
} else {
SendByte(0);
}
// Send footer
SendByte(checksum);
}
void RecvPacket()
{
unsigned char i, len, ID, packetLen;
unsigned char header, footer, checksum;
SendByte(85);
POKE(0x0303, 0); // Set Port A as Input
i = PEEK(0x0301); // Reset ORA
// Check header
if (!RecvByte(&header) || header != 170) {
if (hubState[0] != COM_ERR_OFFLINE) { hubState[0] = COM_ERR_HEADER; }
return;
}
// Get packet ID
if (!RecvByte(&ID)) { hubState[0] = COM_ERR_TRUNCAT; return; }
// Read joystick/mouse data
for (i=1; i<7; i++) {
if (!RecvByte(&hubState[i])) { hubState[0] = COM_ERR_TRUNCAT; return; }
}
// Get buffer length
if (!RecvByte(&len)) { hubState[0] = COM_ERR_TRUNCAT; return; }
// Read buffer data
for (i=0; i<len; i++) {
if (!RecvByte(&recvHub[i])) { hubState[0] = COM_ERR_TRUNCAT; return; }
}
// Get footer
if (!RecvByte(&footer)) { hubState[0] = COM_ERR_TRUNCAT; return; }
// Verify checkum
checksum = ID;
for (i=1; i<7; i++) { checksum += hubState[i]; }
for (i=0; i<len; i++) { checksum += recvHub[i]; }
if (footer != checksum) {
hubState[0] = COM_ERR_CORRUPT;
return;
}
hubState[0] = COM_ERR_OK;
// Check packet reception
if (ID != recvID) {
// Check ID against last packet sent
if ((ID & 0x0f) == sendID) {
// Shift any remaining data
packetLen = sendHub[1]+2;
if (packetLen < sendLen) {
memcpy(&sendHub[0], &sendHub[packetLen], sendLen-packetLen);
sendLen -= packetLen;
} else {
sendLen = 0;
}
}
// Check ID against last packet received
if (len && ((ID & 0xf0) != (recvID & 0xf0)))
recvLen = len;
// Update ID
recvID = ID;
}
}
/code]
Re: 8bit-Unity version 0.3.5
I guess, technically, since the hub is on the printer port, it can "emulate" anything that is based on the printer port, including possibly using it as a way to send actual "print outs" to a PC or maybe even a USB printer?
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: 8bit-Unity version 0.3.5
Great.
On the joystick interface: is there a reason you have chosen a PASE interface over an IJK interface? By no means into the technical details of both myself, but noted that the other new joystick solution that is in development goes the IJK route:
https://forum.defence-force.org/viewtop ... f=9&t=2146 and https://forum.defence-force.org/viewtop ... 2&start=45
Also see here that the PASE interface apparently interferes with sound:
'Because Port A is used to drive the sound generator, using the port for input will corrupt the sound when a switch is closed in the same way that it is when a keyboard key is pressed.'
See here that apparently the IJK interface does not have that issue:
'It connects to the printer port and according to Twilighte, it solved the problem of clashing with the sound.'
Also it would of course be handy if new Oric joystick solutions are as much as possible compatible to each other.
Again, by no means have any technical knowledge of both interfaces myself, just rehashing what I read on this forum and on Google....
On the joystick interface: is there a reason you have chosen a PASE interface over an IJK interface? By no means into the technical details of both myself, but noted that the other new joystick solution that is in development goes the IJK route:
https://forum.defence-force.org/viewtop ... f=9&t=2146 and https://forum.defence-force.org/viewtop ... 2&start=45
Also see here that the PASE interface apparently interferes with sound:
'Because Port A is used to drive the sound generator, using the port for input will corrupt the sound when a switch is closed in the same way that it is when a keyboard key is pressed.'
See here that apparently the IJK interface does not have that issue:
'It connects to the printer port and according to Twilighte, it solved the problem of clashing with the sound.'
Also it would of course be handy if new Oric joystick solutions are as much as possible compatible to each other.
Again, by no means have any technical knowledge of both interfaces myself, just rehashing what I read on this forum and on Google....
Re: 8bit-Unity version 0.3.5
Indeed! In fact, in Oricutron I use the print function to emulate sending codes to the 8bit-Hub!
Customized behaviour can easily be achieved. It is a simple matter of changing the logics inside the HUB, using the Arduino IDE.
See: https://github.com/8bit-Dude/8bit-Hub/b ... 0.ino#L793
Re: 8bit-Unity version 0.3.5
I could implement IJK as well, as long as I have the Oric side assembly code to know how I should present data.xahmol wrote: ↑Tue Oct 20, 2020 9:22 am Great.
On the joystick interface: is there a reason you have chosen a PASE interface over an IJK interface? By no means into the technical details of both myself, but noted that the other new joystick solution that is in development goes the IJK route:
https://forum.defence-force.org/viewtop ... f=9&t=2146 and https://forum.defence-force.org/viewtop ... 2&start=45
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: 8bit-Unity version 0.3.5
Maybe iss as topic starter of the two forumtopics I linked to above could help you with that?
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: 8bit-Unity version 0.3.5
Just received my hub and it works with the tech demos provided! Tested joystick and network access.
Did not test mouse yet as I did not have a PS2 mouse.
Nice work! Now very curious how the Oric community can use and expand it.
Did not test mouse yet as I did not have a PS2 mouse.
Nice work! Now very curious how the Oric community can use and expand it.
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: 8bit-Unity version 0.3.5
By the way: I do not know if it is on purpose as it in the end support a much broader range of 8 bits than only the Atmos, but it perfectly compliments with the Oric Atmos and Cumana Reborn colors.
Think you intended it to be placed to the right of the Atmos with the LCD front facing. That would make more sense apart from me not having space there (as my ZX Spectrum 128 is there now).
So it might just me with this minor issue. Would love to choose orientation of ports next iteration, but not sure if that would screw the internal design to much. And yes, I know, I am fully free to build and assemble my own
Anyway: the colors look great! And all is working,
Minor nagging points on the case design: maybe for a next iteration it would be possible to place the power supply on the side of the COM port instead of the joystick ports? For me it is logical to have joysticks facing front and now also have the powerlead facing front. Especially as the COM cable lacks length and flexibility to place it in much other position than this one.
Think you intended it to be placed to the right of the Atmos with the LCD front facing. That would make more sense apart from me not having space there (as my ZX Spectrum 128 is there now).
So it might just me with this minor issue. Would love to choose orientation of ports next iteration, but not sure if that would screw the internal design to much. And yes, I know, I am fully free to build and assemble my own
Anyway: the colors look great! And all is working,
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: 8bit-Unity version 0.3.5
That is something I did not test yet, just tested basic functionality to see if the hub was functional with the provided demo software.
Network tests that I did were the diagnostic test on the demo disk where the Oric tests if it can send/receive TCP/UDP and an URL. And send and received messages to the shoutbox on the 8Bit unity website from the Oric. See second screenshot above for that.
Also managed to connect in the 8 Bit Slicks game on the Oric to the central server. But no players to play against online, so there the test stopped. But connecting worked.
Definitely want to use this in my own stuff. But no time to do much on that now, also have the hope that much better coding wizards then I am do the hard work on building libraries for that and sample code. Hopefully also usable in BASIC as my assembly and C skills are close to zero.
Of course the 8Bit Unity SDK provides support for the hub. But to use that requires to learn C.
Also, while I have nothing but respect for the effort to make the same code work on multiple machines and it is very cool that it is succeeding, I also see that the necessary compromises needed to cope with the limitations and peculiarities of especially the Oric videochip IMHO opinion does not deliver software that is looking very good....
Again, no offence intended to 8-Bit Dude as I have nothing but respect for the effort. And very curious to see what others will do with it.
But for my own coding efforts I came to the conclusion that writing specifically for the Oric gives better looking software. At the moment busy converting one of my old C128 programs (the Ludo boardgame) to the Oric and quickly found out that the whole screen design should be done from scratch on the Oric to have nice looking graphics and colors. Mainly because on the Oric attributes to change color and change charset take up space not usable for something else. While all other 8 bits that I ever programmed for store color attributes in a seperate memory area. Also the Oric using 6x8 pixel characters instead of 8x8 on all my other 8 bits is something that really needs a specific design for.
Hard to cope with both if the code has to be multi platform.
But as the 8 Bit Unity SDK is open source, it definitely should be usable also without using the full SDK.
Would be super to have network multiplayer support in my boardgame. Will be hard and a lot of work I am afraid though without libraries or standard services to use. See that even on modern devices multiplayer network implementation of boardgames is a major hassle to do right, as you have to cope with so many things that can go wrong.... (not only your own local machine, but also the server and all other local clients connecting, including all connectivity between them).
Network tests that I did were the diagnostic test on the demo disk where the Oric tests if it can send/receive TCP/UDP and an URL. And send and received messages to the shoutbox on the 8Bit unity website from the Oric. See second screenshot above for that.
Also managed to connect in the 8 Bit Slicks game on the Oric to the central server. But no players to play against online, so there the test stopped. But connecting worked.
Definitely want to use this in my own stuff. But no time to do much on that now, also have the hope that much better coding wizards then I am do the hard work on building libraries for that and sample code. Hopefully also usable in BASIC as my assembly and C skills are close to zero.
Of course the 8Bit Unity SDK provides support for the hub. But to use that requires to learn C.
Also, while I have nothing but respect for the effort to make the same code work on multiple machines and it is very cool that it is succeeding, I also see that the necessary compromises needed to cope with the limitations and peculiarities of especially the Oric videochip IMHO opinion does not deliver software that is looking very good....
Again, no offence intended to 8-Bit Dude as I have nothing but respect for the effort. And very curious to see what others will do with it.
But for my own coding efforts I came to the conclusion that writing specifically for the Oric gives better looking software. At the moment busy converting one of my old C128 programs (the Ludo boardgame) to the Oric and quickly found out that the whole screen design should be done from scratch on the Oric to have nice looking graphics and colors. Mainly because on the Oric attributes to change color and change charset take up space not usable for something else. While all other 8 bits that I ever programmed for store color attributes in a seperate memory area. Also the Oric using 6x8 pixel characters instead of 8x8 on all my other 8 bits is something that really needs a specific design for.
Hard to cope with both if the code has to be multi platform.
But as the 8 Bit Unity SDK is open source, it definitely should be usable also without using the full SDK.
Would be super to have network multiplayer support in my boardgame. Will be hard and a lot of work I am afraid though without libraries or standard services to use. See that even on modern devices multiplayer network implementation of boardgames is a major hassle to do right, as you have to cope with so many things that can go wrong.... (not only your own local machine, but also the server and all other local clients connecting, including all connectivity between them).
Last edited by xahmol on Thu Oct 29, 2020 10:24 am, edited 9 times in total.
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: 8bit-Unity version 0.3.5
Was surprised the package came from Japan. Could have known of course, and was also surprised postage from Japan was actually very quick including customs.
Just a bummer that of course I had to pay import duties as it was from outside the EU (20 euro in my case), but also that process luckily went very fast and smooth.
Funny. Send 19 October and received 28 October, much 8 bit stuff ordered from within the EU actually took almost twice as long....
Just a bummer that of course I had to pay import duties as it was from outside the EU (20 euro in my case), but also that process luckily went very fast and smooth.
Funny. Send 19 October and received 28 October, much 8 bit stuff ordered from within the EU actually took almost twice as long....
Re: 8bit-Unity version 0.3.5
Well, mine was also sent the 19th, the tracking information says it left OSAKA on the 20th, but since then, nothing on the radar
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: 8bit-Unity version 0.3.5
Haha, Dutch post perhaps more efficient than French post?
Actually, shipping from France to Netherlands last month took much longer than this package from Japan....
Actually, shipping from France to Netherlands last month took much longer than this package from Japan....