RedC in development
- Thread starter bahstrike
- Start date
Correcticus.. It's a complete IDE for writing new redpower computer OS in glorious, glorious C.
RedC is...
Code Editor
Supports syntax highlighting, automatic indentation, etc.
Uses the same text editor control as Notepad++.
C Compiler
Powered by cc65 (open-source 6502 compiler).
I'm continuing L. Adamson's work on machine target to properly support the RPC8.
Built-in Simulator
Build project and automatically launch BiGFooT's Emulator with your OS.
Minecraft Integrated
Scan your player inventory and select a floppy disk for the project.
Build project and automatically import your OS to disk on live server.
Motivation for this project?
Computercraft is amazing, but.. doesn't have enough redstone I/O, a bad program can crash the server, and its lua editor is weaksauce.
Totally not wasting time with FORTH on larger projects (sorry Eloraam!).
BiGFooT's BASIC disk image is brilliant; but some might consider BASIC inappropriate for complex projects.
RedC is...
Code Editor
Supports syntax highlighting, automatic indentation, etc.
Uses the same text editor control as Notepad++.
C Compiler
Powered by cc65 (open-source 6502 compiler).
I'm continuing L. Adamson's work on machine target to properly support the RPC8.
Built-in Simulator
Build project and automatically launch BiGFooT's Emulator with your OS.
Minecraft Integrated
Scan your player inventory and select a floppy disk for the project.
Build project and automatically import your OS to disk on live server.
Motivation for this project?
Computercraft is amazing, but.. doesn't have enough redstone I/O, a bad program can crash the server, and its lua editor is weaksauce.
Totally not wasting time with FORTH on larger projects (sorry Eloraam!).
BiGFooT's BASIC disk image is brilliant; but some might consider BASIC inappropriate for complex projects.
but but but I hate string management in C so much 
Yes I know all the counterarguments (I programmed in C for 20 years) but C# is where its at. I love the sugar, I love the coddling and handholding. I love the not thinking. Give me my not thinking please.
(kidding, I'm not asking for anything. Good work man)
Yes I know all the counterarguments (I programmed in C for 20 years) but C# is where its at. I love the sugar, I love the coddling and handholding. I love the not thinking. Give me my not thinking please.
(kidding, I'm not asking for anything. Good work man)
Dev Diary
Replaced IDE *.c (C Source File) file format with *.rc (RedC Project) file format.
This will include the sourcecode plus project settings (such as DiskID) in a single file.
Currently, multi-file projects are not planned. You could work around these with #includes.
Some progress on minecraft integration- can iterate through player floppy disks and locate the disk image file in world path.
Initial 'live injection' to disk is working, for local server.
Eventual plan is to have full MP support- server admin runs a service app that allows players to submit disk image data.
Will include an authentication scheme; probably a "please hold XX sand blocks in first inventory slot and click next" to allow server to verify user is actual accountholder of indicated playername.
Definitely discovering some problems in the work previously done by Adamson; can't switch redbus targets inside a loop.
Perhaps something silly like not restoring registers or status register flags. Will solve this weekend.
For an initial alpha release, I do not intend to implement the full CRT. I want to make available something
stable&working for everyone. File system and full stdin / stdout support can come later.
Replaced IDE *.c (C Source File) file format with *.rc (RedC Project) file format.
This will include the sourcecode plus project settings (such as DiskID) in a single file.
Currently, multi-file projects are not planned. You could work around these with #includes.
Some progress on minecraft integration- can iterate through player floppy disks and locate the disk image file in world path.
Initial 'live injection' to disk is working, for local server.
Eventual plan is to have full MP support- server admin runs a service app that allows players to submit disk image data.
Will include an authentication scheme; probably a "please hold XX sand blocks in first inventory slot and click next" to allow server to verify user is actual accountholder of indicated playername.
Definitely discovering some problems in the work previously done by Adamson; can't switch redbus targets inside a loop.
Perhaps something silly like not restoring registers or status register flags. Will solve this weekend.
For an initial alpha release, I do not intend to implement the full CRT. I want to make available something
stable&working for everyone. File system and full stdin / stdout support can come later.
Dev Diary
Added 'Output' pane (hotlinks bring you to warning/error line).
Added 'Disassembly' pane.
Fixed the rpc8e lib calling convention issue with being unable to switch redbus targets.
Still working on understanding some of the remaining funk like for(x=0; 10>x; x++) works but for(x=0; x<10; x++) doesn't..
That's the major thing left before I can push out a milestone release.
Added 'Output' pane (hotlinks bring you to warning/error line).
Added 'Disassembly' pane.
Fixed the rpc8e lib calling convention issue with being unable to switch redbus targets.
Still working on understanding some of the remaining funk like for(x=0; 10>x; x++) works but for(x=0; x<10; x++) doesn't..
That's the major thing left before I can push out a milestone release.
Dev Diary
Well, I'm pretty sure I just found a bug in the redpower CPU.
If executing SBC #$00 with an accumulator value of 00, without the carry flag set, the result is 0xFF.
In other words, sometimes zero minus zero equals 255
This is the deep nasty reason why for(x=0; x<10; x++) was not working, at all.
I'll have to check the cc65 source for anywhere else it constructs an SBC instruction, and if the carry flag is not guaranteed to be set, add a way to zero out the accumulator.
Not sure whether this will be a custom cc65 executable, or perhaps just parsing the assembly output and recognizing certain scenarios to inject the workaround (preserving the original cc65 suite).
This is a great discovery- the largest problem with compiling C code for the redpower computer is finally understood!
I plan to push out an alpha release of RedC by this weekend.
Well, I'm pretty sure I just found a bug in the redpower CPU.
If executing SBC #$00 with an accumulator value of 00, without the carry flag set, the result is 0xFF.
In other words, sometimes zero minus zero equals 255
This is the deep nasty reason why for(x=0; x<10; x++) was not working, at all.
I'll have to check the cc65 source for anywhere else it constructs an SBC instruction, and if the carry flag is not guaranteed to be set, add a way to zero out the accumulator.
Not sure whether this will be a custom cc65 executable, or perhaps just parsing the assembly output and recognizing certain scenarios to inject the workaround (preserving the original cc65 suite).
This is a great discovery- the largest problem with compiling C code for the redpower computer is finally understood!
I plan to push out an alpha release of RedC by this weekend.
Dev Diary
Sorry I indicated possible alpha release and then didn't follow through. This SBC discrepancy needs to be solved, first.
It's been on my mind, but haven't actively worked on it until now.
Figured since I didn't get the opportunity to do any programming at my programming job today, I'd do some when I got home.
Turns out I was wrong in initially reporting redpower bug where 0 - 0 = 255. This is actually correct when carry flag is clear (part of 2's complement support or whatnot).
Instead, the RPC bug is the fact that the overflow flag is set as a result, whereas another 6502 simulator clears it.
Considering the following instruction is a BVC (branch if overflow clear), and the RPC does not take the branch when it really should, I think is proof this is the legitimate problem.
The theory is also backed up by an article which states there is some misinformation about handling of V flag in a couple of instructions; including SBC.
So I guess my next task is to fully understand the scenarios in which V is supposed to be set or reset by SBC, inject some workarounds, THEN release an alpha
Sorry I indicated possible alpha release and then didn't follow through. This SBC discrepancy needs to be solved, first.
It's been on my mind, but haven't actively worked on it until now.
Figured since I didn't get the opportunity to do any programming at my programming job today, I'd do some when I got home.
Turns out I was wrong in initially reporting redpower bug where 0 - 0 = 255. This is actually correct when carry flag is clear (part of 2's complement support or whatnot).
Instead, the RPC bug is the fact that the overflow flag is set as a result, whereas another 6502 simulator clears it.
Considering the following instruction is a BVC (branch if overflow clear), and the RPC does not take the branch when it really should, I think is proof this is the legitimate problem.
The theory is also backed up by an article which states there is some misinformation about handling of V flag in a couple of instructions; including SBC.
So I guess my next task is to fully understand the scenarios in which V is supposed to be set or reset by SBC, inject some workarounds, THEN release an alpha
So... let me see if I got this right...
When I feel raged with C and all his horrible problems like debugging, instead of working and developing some kind of program for my boss, I will open mine MC instance, open the RC editor and develop some kind of C program, while suffering from the same horrible problems and cursing C debugger but somehow feeling happy coz I'm playing MC?
Still, very cool project/mod/tool/whatever you have there!
When I feel raged with C and all his horrible problems like debugging, instead of working and developing some kind of program for my boss, I will open mine MC instance, open the RC editor and develop some kind of C program, while suffering from the same horrible problems and cursing C debugger but somehow feeling happy coz I'm playing MC?
Still, very cool project/mod/tool/whatever you have there!
Haha me? No, I get sucked into emails and phone calls and "hey quick question" and even conducting an interview.. it is what it is, but it ain't programming. Had to go home to get my fixSo... let me see if I got this right...
When I feel raged with C and all his horrible problems like debugging, instead of working and developing some kind of program for my boss, I will open mine MC instance, open the RC editor and develop some kind of C program, while suffering from the same horrible problems and cursing C debugger but somehow feeling happy coz I'm playing MC?
Still, very cool project/mod/tool/whatever you have there!
Right now I'm looking at the sourcecode for other 6502 simulator to see how it handles the SBC instruction- and it's a bit fun since the author is Polish.. have to keep jumping to Google translate to read his comments.
..and yes, the guy got the job..
Last edited:
Dev Diary
SBC bug update.. nearly positive I've got it figured.
This little detail (bolded) is the reason I was very confused by 0 - 0 = 255 when the carry flag is NOT set.
Apparently this quirk was by design, only to make the most out of the available die fabric back in the 70's.
Intel 8086's SBB (SuBtract with Borrow): Result = A - (B + CarryFlag)
6502's SBC (SuBtract with Carry): Result = A - (B + !CarryFlag)
So that explains that.. But the real question is wtf's up with the overflow flag?
Well I've found the answer.
Carry flag is cleared. Therefore SBC will calculate 0 - (0 + 1):
So it seems to makes sense to set the overflow flag since 0 - 1 = 255 is definitely an underflow event.
Sheesh- sorry Eloraam, don't shoot me but, it seems (by extension) that may not be correct!!
According to the bottom of page 3 of this PDF, regarding Intel 8086's SBB instruction (presumably by extension, the same thinking behind 6502's SBC):
"...the overflow flag will be set to 1 to indicate that the result is out of the range of byte-sized signed numbers..."
Overflow should not be set!
SBC bug update.. nearly positive I've got it figured.
This little detail (bolded) is the reason I was very confused by 0 - 0 = 255 when the carry flag is NOT set.
Apparently this quirk was by design, only to make the most out of the available die fabric back in the 70's.
Intel 8086's SBB (SuBtract with Borrow): Result = A - (B + CarryFlag)
6502's SBC (SuBtract with Carry): Result = A - (B + !CarryFlag)
So that explains that.. But the real question is wtf's up with the overflow flag?
Well I've found the answer.
Carry flag is cleared. Therefore SBC will calculate 0 - (0 + 1):
- In 8-bit signed integer math, this will produce -1 (0xFF in two's complement).
- In 8-bit unsigned integer math, this will underflow and produce 255 (0xFF in unsigned).
So it seems to makes sense to set the overflow flag since 0 - 1 = 255 is definitely an underflow event.
Sheesh- sorry Eloraam, don't shoot me but, it seems (by extension) that may not be correct!!
According to the bottom of page 3 of this PDF, regarding Intel 8086's SBB instruction (presumably by extension, the same thinking behind 6502's SBC):
"...the overflow flag will be set to 1 to indicate that the result is out of the range of byte-sized signed numbers..."
- 0 - 1 = -1
- -1 is 0xFF, in two's complement
- 0xFF is in range of byte-sized signed numbers
Overflow should not be set!
You may have already seen this, but it might be of interest: http://www.righto.com/2012/12/the-6502-overflow-flag-explained.html
Ooh, no I haven't seen that article- sweet find. The linked 'silicon level' article is very cool.
Looks like redpower CPU uses the same overflow detection algorithm as suggested by the article.
I was very wrong in thinking Eloraam was misinterpreting the meaning of overflow- rather presumptuous of me.
Luckily this means that addition (ADC) is fine.
However there is indeed a bug; and it will ONLY occur when subtracting 0 with carry.
Here's the redpower CPU's SBC implementation:
int v = ((regA - val) + (flagC ? 1 : 0)) - 1;
flagC = (v & 0x100) == 0;
flagO = ((v ^ regA) & (v ^ -val) & 0x80) > 0;
regA = v & 0xff;
This would all work
if the first line were rewritten to:if(!flagC) val++;
int v = regA - val;
After some automated testing on her implementation above, the overflow status is only wrong for 127 - 0 (should set overflow, but doesn't) and 0 - 0 (shouldn't set overflow, but does).
This means a magic trick is possible- no nasty JSRs trying to reimplement the overflow logic.. Just a gentle coax to make the RPC swap it's behavior.
Just need a lil hack to look for any SBC not preceded by a SEC, then replace it with:
PHP
EOR #$80
PLP
{ original SBC instruction }
PHP
EOR #$80
PLP
Shaziing!
bahstrike
Looks like you did some amazing work here and judging by how many posts you got (too few) people arent appreciating your work like I do!.
Is this still in development? Since I'm very much intersted in this project as I'm making a private mod for myself+a few friends that brings RedPower to the 1.7.10 version of MineCraft (obviously it cant be publically released since Eloraam would scream bloody murder rather than simply be HAPPY somebody ported the mod and fixed all the bugs but that wont stop us from doing it privately) and your tool would be ideal for us to use.
We have the added the MS-BASIC disk to our mod so the players have a choice of OS for the computer FORTH or MS-BASIC we would like to make an OS in C and RedC seems to be the ideal solution.
If you don't wish to finsh RedC you could turn it over to us.
Anyway let me know whats happening with RedC and if you are still up to the task my e-mail is:
[email protected]
Looks like you did some amazing work here and judging by how many posts you got (too few) people arent appreciating your work like I do!.
Is this still in development? Since I'm very much intersted in this project as I'm making a private mod for myself+a few friends that brings RedPower to the 1.7.10 version of MineCraft (obviously it cant be publically released since Eloraam would scream bloody murder rather than simply be HAPPY somebody ported the mod and fixed all the bugs but that wont stop us from doing it privately) and your tool would be ideal for us to use.
We have the added the MS-BASIC disk to our mod so the players have a choice of OS for the computer FORTH or MS-BASIC we would like to make an OS in C and RedC seems to be the ideal solution.
If you don't wish to finsh RedC you could turn it over to us.
Anyway let me know whats happening with RedC and if you are still up to the task my e-mail is:
[email protected]