The early stages of my Computercraft emulator

http://youtu.be/PJ7WxTBamws

Currently it cannot read keys through the screen, not all APIs are implemented, and it doesn't use the CC font due to a bug (and if you think you know how to fix it, the associated code (and the place i prefer your solution) is here)
It's basically just a lua output window.

Should i put it on GitHub or is it too early yet?

This error is produced from the computercraft's own bios.lua.
Making progress!

The emulator now has a GitHub page: https://github.com/Admicos/CCPY
If you want to help, go right there!

This error happens at rom/apis/colours Line 3 and is the only error currently blocking progress. It thinks colors is a "userdata" when it's a table. Any help appriciated

EDIT: Also a error at rom/apis/term line 45, but that's due to how native is (NOT) implemented. A fix for that would be appriciated too..

Are you sure you're passing a Lua table and not a custom wrapper object?

CrazedProgrammer, on 31 August 2016 - 09:34 AM said:

Are you sure you're passing a Lua table and not a custom wrapper object?

I AM actually passing a custom class, why didn't i think of remaking it in Lua. (sighs)

I guess programming without sleep REALLY doesn't work.

EDIT: That actually worked!

No problem, glad I could help!

I love CC emulators, I'm excited to see how yours does!

I think i fixed the term.native error, but i am now stuck with "attempt to yield across C-Call boundary" which i have absolutely no idea how to fix.

EDIT: It might be due to a function that isn't implemented as bios.lua 178 (where the error probably happens) is os.pullEventRaw, which isn't implemented.
EDIT 2: Confirmed, as implementing it will change the error.
EDIT 3: Getting the same error again. os.pullEventRaw is implemented(-ish as the filter currently doesn't work)
EDIT 4: There are a error i couldn't see. Let's see what it is
EDIT 6: It seems like it can't iterate over "native" in the term API. I think i know why though
EDIT 7: Does someone know how to send Python classes in Lua as modifiable, because i think that's the issue (probably not, and it's probably modifiable by default.)

As an educated guess, it sounds like you're trying to run bios.lua directly, as opposed to running it within a Lua coroutine. CC sticks it within one so that the one VM can run one copy for each active system in the world - your emulator will presumably only handle one system at a time, but bios.lua expects to be running within a coroutine regardless.

In psuedocode (you may not even be using Lua for this directly):

local myCoroutine = coroutine.create(loadfile("bios.lua"))
local ok, requestedEvent = coroutine.resume(myCoroutine)

while coroutine.status(myCoroutine) ~= "dead" do
        -- Generate an event, put its parameters into a table called eg "myEvent".
        -- If you have nothing to generate an event with (eg the user hasn't typed anything, no timers have expired, yadda yadda,
        --    ... then pause here until you do.

        if not requestedEvent or requestedEvent == myEvent[1] then
        	ok, requestedEvent = coroutine.resume(myCoroutine, unpack(myEvent))
        end
end

-- End emulation, system has stopped.

Assuming you're already familiar with coroutines, it may still be worth reading chapter four onwards of this. If it doesn't make sense, then you may instead be better off reading the whole thing.

Bomb Bloke, on 02 September 2016 - 06:19 AM said:

As an educated guess, it sounds like you're trying to run bios.lua directly, as opposed to running it within a Lua coroutine. CC sticks it within one so that the one VM can run one copy for each active system in the world - your emulator will presumably only handle one system at a time, but bios.lua expects to be running within a coroutine regardless.

In psuedocode (you may not even be using Lua for this directly):

local myCoroutine = coroutine.create(loadfile("bios.lua"))
local ok, requestedEvent = coroutine.resume(myCoroutine)

while coroutine.status(myCoroutine) ~= "dead" do
		-- Generate an event, put its parameters into a table called eg "myEvent".
		-- If you have nothing to generate an event with (eg the user hasn't typed anything, no timers have expired, yadda yadda,
		--	... then pause here until you do.

		if not requestedEvent or requestedEvent == myEvent[1] then
			ok, requestedEvent = coroutine.resume(myCoroutine, unpack(myEvent))
		end
end

-- End emulation, system has stopped.

Assuming you're already familiar with coroutines, it may still be worth reading chapter four onwards of this. If it doesn't make sense, then you may instead be better off reading the whole thing.

Thanks for the info.

EDIT: If my memory is correct, then this just fixed a error, i think. (there is still one though, i think i have an idea)

I can (posssibly) run the shell now as the error suggests that it tries to open the shell.

Now let's tune the fs api a bit and try now.

guys?



Make a filler RS api and possibly no errors!

EDIT: No errors on the shell, yay! Now let's try events.
EDIT 2: Events are now causing the c-call boundary error, i'm gonna try some more stuff.
EDIT 3: Also, the events don't register either. Let me try a different method.
EDIT 4: Events now register properly, now let't try the cc part.
EDIT 5: I made the events all in Lua, to hopefully be more compatible. But still no CC reaction.
EDIT 6: I just saw that bios.lua implements its own pullEventRaw that is just a coroutine.yield. *facepalming intensifies*

http://www.youtube.com/watch?v=pBB6HeSwbIs

I think i just got a modified bios to get the events, but they are all nil, gotta figure this out.

My experience with Python is minimal, but if I'm reading things correctly, your code may incorrectly resume the computer's coroutine here - this "update" method gets called every time the loop here notices an event, but not every event pygame.event.wait() collects is added to the CC system's queue.

You should not resume CC's coroutine if you have no relevant events to pass in, and you should furthermore discard any events which mismatch a set event filter (other than "terminate").

I don't know if you're still working on this, but the computercraft font has all the letters centered in their little rectangle in the terminal's grid rather than leaning to the left

ashnwill, on 09 October 2016 - 05:09 AM said:

I don't know if you're still working on this, but the computercraft font has all the letters centered in their little rectangle in the terminal's grid rather than leaning to the left

i know and i'm trying to fix it, and i kind of stopped it for a month or so, will try to make it work once github gets unblocked :(/>

Admicos, on 09 October 2016 - 04:20 PM said:

i know and i'm trying to fix it, and i kind of stopped it for a month or so, will try to make it work once github gets unblocked :(/>

Damn, man. It must be a horrible time to live in Turkey, huh? Can you access the Tor project?

EldidiStroyrr, on 20 October 2016 - 12:47 PM said:

Admicos, on 09 October 2016 - 04:20 PM said:

i know and i'm trying to fix it, and i kind of stopped it for a month or so, will try to make it work once github gets unblocked :(/>

Damn, man. It must be a horrible time to live in Turkey, huh? Can you access the Tor project?

It's unblocked already and yes i can access Tor.

Will we be able to use custom CC versions with this?
Or does it implement CC?

Piorjade, on 21 October 2016 - 08:08 PM said:

Will we be able to use custom CC versions with this?
Or does it implement CC?

It "implements" cc, so nothing to do with the original jar other than the bios files, but it's still incomplete (just the events missing, but i'll try to fix it later)

[media]http://www.youtube.com/watch?v=CfeX1PBqEPs[/media]

So, i got events working to the point where you can type into the shell, but they are still buggy and most events do not exist.
And due to LWJGL and Pygame having different key codes, most non-letter keys do not work. If they worked, the cc shell would probably run without problems though.

EDIT: So, i made the events work faster by making the event queue return the last item instead of the first item. But i still need to implement proper key mapping and the rest of the events

The current state of the emulator:
[media]http://www.youtube.com/watch?v=Ig_S8Bh99G8[/media]

Considering the emulator couldn't even handle keypresses yesterday, this is some good progress right here!

Pretty late update: I changed the renderer from using TTF fonts to using CC's term_font.png file. So the current rendering is pretty accurate i'd say.



Now I need to do key combinations, but I think that will need seperate files for each keyboard layout unless I can find a way to do it easier.

Admicos, on 18 May 2017 - 08:33 AM said:

Pretty late update: I changed the renderer from using TTF fonts to using CC's term_font.png file. So the current rendering is pretty accurate i'd say.



Now I need to do key combinations, but I think that will need seperate files for each keyboard layout unless I can find a way to do it easier.

If I'm not mistaken, you just need to keep track of keydown and keyup events. on a keydown event where a status key (shift,ctrl,alt,etc.) is pressed, set a corresponding bool and when they are released, set the bool to false. If I knew where input was being handled, I could probably submit a PR to do this myself.

EDIT: using a test program, I found the key events for modifier keys:

Control key = 29
Alt key = 56
Shift key = 42

if you queue said events, programs should run without a hitch.

So, after almost a year of not doing anything with this, I decided to rewrite it. I managed to get this up to about the same level of functionality in about 4 days using some copy-paste and generally knowing how to handle stuff properly. Now the code is MUCH cleaner and it also has some tests too. (No idea how to test anything internal, so I just tested the APIs exposed to CC, except FS because I know that's broken. Gotta fix that someday)

Also, HTTP support:


The new code is over at https://gitlab.com/admicos/ccpy if anyone's interested.

I managed to split the emulator's display and event handling to different "Drivers". This makes cleaner code and has the possibility to allow fun stuff like running the emulator totally headless, displaying on a CLI or simply using a different renderer if pygame doesn't work for some reason.

I re-wrote the path sanitizer, so most fs bugs should (I hope) be fixed. I also added tests to the fs API so the emulator's at 90% coverage now. (Doesn't mean much but I like seeing nice numbers)

The emulator should be pretty usable (assuming there aren't any other bugs or other stuff I might've missed) when I fix the key handling.

Finally! Key events are fixed and should work pretty well!

Now that that's out of the way, I might actually consider using this for anything other than testing if it works or not.