Coding a 256 bytes prod on Oric anyone ?
category: general [glöplog]
I know there are quite impressive things coded in 256 bytes on the PC, and there are also nice stuff on both
Atari XL/XE and
C64
(strangely it seems there are not on the VIC 20 ?)
This lead me to wonder what could be achieved on the Oric in 256 bytes.
Since just releasing a single 256 bytes intro out of nowhere directly on pouet does not seem like a particularly interesting feat, I was more thinking of doing a compilation of 256 bytes prod made by various people.
So well, I openned a topic about that on the Oric forum, that go a tremendous success: I receive ONE prod written in Basic (thanks to you Peter for the effort).
So with mine, that's already TWO prods... yeah yeah great.
In short, if anyone here with experience on 6502 assembly code (or if you are just interested by trying), you are welcome in sending me anything in 256 byte that can run on the oric :)
You can use BASIC, you can use pure assembly code (you can set the load adress to any area you wish, including the top 16k - the overlay memory can be overwritten)...
If you never coded anything in 6502, and wish to eventually start doing stuff on the C64, it's a good way to start: most of the things that you learn on the Oric work "out of the box" on the C64 (reverse is not true :p).
You can find some stuff to help developping here:
The (windows only sorry) OSDKthat includes C compiler, assembler, libraries, some documentation, ...
Some explanations about how the video display work
And well, you can post messages on the Oric forum too if you have any questions/suggestions.
I lowered my expectation, instead of waiting for 256 intros to release the compilation, I will wait until I got about 16 of them :)
Atari XL/XE and
C64
(strangely it seems there are not on the VIC 20 ?)
This lead me to wonder what could be achieved on the Oric in 256 bytes.
Since just releasing a single 256 bytes intro out of nowhere directly on pouet does not seem like a particularly interesting feat, I was more thinking of doing a compilation of 256 bytes prod made by various people.
So well, I openned a topic about that on the Oric forum, that go a tremendous success: I receive ONE prod written in Basic (thanks to you Peter for the effort).
So with mine, that's already TWO prods... yeah yeah great.
In short, if anyone here with experience on 6502 assembly code (or if you are just interested by trying), you are welcome in sending me anything in 256 byte that can run on the oric :)
You can use BASIC, you can use pure assembly code (you can set the load adress to any area you wish, including the top 16k - the overlay memory can be overwritten)...
If you never coded anything in 6502, and wish to eventually start doing stuff on the C64, it's a good way to start: most of the things that you learn on the Oric work "out of the box" on the C64 (reverse is not true :p).
You can find some stuff to help developping here:
The (windows only sorry) OSDKthat includes C compiler, assembler, libraries, some documentation, ...
Some explanations about how the video display work
And well, you can post messages on the Oric forum too if you have any questions/suggestions.
I lowered my expectation, instead of waiting for 256 intros to release the compilation, I will wait until I got about 16 of them :)
Got the Oric now, but no suitable devkit ):
Will just be trying 6502 code on it then, because the concept of 'installing windows in order to use an Oric Devkit' is just silly (:
Will just be trying 6502 code on it then, because the concept of 'installing windows in order to use an Oric Devkit' is just silly (:
Well, we used to get somebody working on a linux port, but well... never finished it.
You can still download the devkit, it's a standard zip, and even if you cannot run it, you still have access to the source code of all libraries, sample code, and html documentation (with memory map and stuff like that).
You can still download the devkit, it's a standard zip, and even if you cannot run it, you still have access to the source code of all libraries, sample code, and html documentation (with memory map and stuff like that).
you could use wine to use the devkit?
you could be fat?
nosfe: naw, that's just silly (: It's a 6502 based machine, we've got compilers and so on. Dbug pointed out that it's not 100% unusable, which I hadn't checked before. The documentation and the example source are all I really need, and THAT of course doens't require Windows.
after reading the hardware-specs, i strongly believe you won't raise much interesst for this machine.
hellfire: Well the machine already raised more interest that anyone would have been thinking possible in first place, so I'm not looking for much more in this domain :)
Some of the Oric prods got more than one page of comments on pouet, that by itself is already an achievement by my criteria !
Now well, for what I know, coders are not only interested by machines that have strong hardware specs. Doing anything remotely decent looking/cool on what is probably the most underpowered 6502 based machine ever built can be an interesting challenge.
Some of the Oric prods got more than one page of comments on pouet, that by itself is already an achievement by my criteria !
Now well, for what I know, coders are not only interested by machines that have strong hardware specs. Doing anything remotely decent looking/cool on what is probably the most underpowered 6502 based machine ever built can be an interesting challenge.
hellfire, bah. oric is a cute machine and needs definetly more prods. :)
Thumbs up for the devkit, which was easy and fun to use. I might have some fun with this at some point :)
anarcho-syndicalist machine! \o/
Preacher: if you wish to test on real hardware, let me know, as I've got the Atmos that Twilighte brought at Asm.
Dbug: vic20 is strong too, don't forget Viznut, Heatbeat, and Britelite (:
Dbug: vic20 is strong too, don't forget Viznut, Heatbeat, and Britelite (:
I DLed the SDK and thought I would give it a try, but even if I took the example "hello-world" assembly program, stripped it down to this:
_main
ldx #0
loop_char
read
lda message,x
beq end_loop_char
write
sta $bb80,x
inx
jmp loop_char
end_loop_char
rts
message
.asc "Hello World !",0
It produces an .TAP-file which is over 400 bytes!? I checked the binary, and while it seems padded with lots of zeroes (and a Dbug at the end.. hmm.. :)) even the "real" data seems to be over 200 bytes. What is up with that?
I would have expected to get a binary of about 33 bytes from that. Does the .tap format have a lot of overhead, and in that case how do you know the "real" size.
_main
ldx #0
loop_char
read
lda message,x
beq end_loop_char
write
sta $bb80,x
inx
jmp loop_char
end_loop_char
rts
message
.asc "Hello World !",0
It produces an .TAP-file which is over 400 bytes!? I checked the binary, and while it seems padded with lots of zeroes (and a Dbug at the end.. hmm.. :)) even the "real" data seems to be over 200 bytes. What is up with that?
I would have expected to get a binary of about 33 bytes from that. Does the .tap format have a lot of overhead, and in that case how do you know the "real" size.
Sdw: Good remark :)
Originaly the assembler was just used as a back end for the compiler, and the linker use to add some stuff at the begining and the end to initialise some stack/system variable stuff (prolog/epilog). Looks like I need to update the documentation :)
Just add the two following lines in the osdk_config.bat file:
SET OSDKLINK=-B
SET OSDKHEAD=-S1
The OSDKLINK=-B thing is to force the linker to not add additional library stuff. From this point it means that calling library functions will probably crash, but well, that's life :)
The OSDKHEAD=-S1 is just some added verbosity to know exactly the size of stuff. On the original hello world it will display this:
Building the program HWASM at adress $800
Assembling main.S
Linking
Assembling
Creating final program HWASM.TAP
File 'build\HWASM.tap' is 63 bytes long (14 bytes header and 49 bytes of data)
Build of HWASM.tap finished
With your stripped down version:
File 'build\HWASM.tap' is 43 bytes long (14 bytes header and 29 bytes of data)
The main idea behind the OSDK was to get something easy to get on for beginers, while still having the possibility to remove the fluff to get to the metal if you really want it :)
Originaly the assembler was just used as a back end for the compiler, and the linker use to add some stuff at the begining and the end to initialise some stack/system variable stuff (prolog/epilog). Looks like I need to update the documentation :)
Just add the two following lines in the osdk_config.bat file:
SET OSDKLINK=-B
SET OSDKHEAD=-S1
The OSDKLINK=-B thing is to force the linker to not add additional library stuff. From this point it means that calling library functions will probably crash, but well, that's life :)
The OSDKHEAD=-S1 is just some added verbosity to know exactly the size of stuff. On the original hello world it will display this:
Building the program HWASM at adress $800
Assembling main.S
Linking
Assembling
Creating final program HWASM.TAP
File 'build\HWASM.tap' is 63 bytes long (14 bytes header and 49 bytes of data)
Build of HWASM.tap finished
With your stripped down version:
File 'build\HWASM.tap' is 43 bytes long (14 bytes header and 29 bytes of data)
The main idea behind the OSDK was to get something easy to get on for beginers, while still having the possibility to remove the fluff to get to the metal if you really want it :)