Gamebuino forum

Myndale wrote:[quote="cyberic"I've got no news... did you get my PM?

Strange, I thought I emailed you. I'll go check and mail you again, thanks![/quote]
No, no mail and nothing in spam folder...

Myndale, it appears as if the EEPROM you programmed doesn't support writing all 1024 bytes. It only supports writing the first 256 bytes. Or, perhaps the EEPROM.read only supports *reading* the first 256 bytes.

Code: Select all

// Write 0 to 255
for (uint16_t i = 0; i < 256; i++) {
    EEPROM.write(i, i);
}

// Read everything.
for (uint16_t i = 0; i < 1024; i++) {
    Serial.print(EEPROM.read(i));
    Serial.print(", ");
}


It should print 0 to 255, followed by a bunch of 255s (uninitialized EEPROM should be 255). Instead, it prints 0-255 four times. Meaning your simulated EEPROM.read takes an argument of a byte instead of an int16_t or uint16_t.

I ran code on the Gamebuino to confirm the improper behavior of the emulator.

In other news, have you considered open-sourcing it :3

Jamish wrote:Myndale, it appears as if the EEPROM you programmed doesn't support writing all 1024 bytes. It only supports writing the first 256 bytes. Or, perhaps the EEPROM.read only supports *reading* the first 256 bytes.

Wow, I'm surprised that one hasn't manifested itself sooner, thx Jamish! As it turns out it wasn't anything to do with EEPROM at all, it was a bug in one of the assembly branch instructions that caused an extra instruction to be skipped under certain circumstances. Your code exposed it though so thanks again.

Jamish wrote:In other news, have you considered open-sourcing it

TBH I had a bad experience with open source and I've been a bit wary of opening up any of my serious projects ever since. Not ruling it out permanently, just saying "not at this time".

Yay, you already know the fix! Good work.

As far as open source goes, I can respect that.

New version of Simbuino uploaded with the following change list:

• Added port refresh prior to hardware upload.
• Fixed a bug where all buttons were appearing as pressed after a ctrl-f5.
• Fixed an eeprom display bug.
• Fixed a logic bug in sbic instruction.

Thanks again for the bug reports.

Just had a crazy (but useful) idea for a Feature: emulation of MULTIPLE Gamebuinos.

I know it would be hard to implement, but this could help make a lot more multiplayer games.
Do you think it needs real time connections, or is the delay so small that it's not even worth it?

Good idea, but the emulation code is currently too slow to run multiple simulations. There is one major speed-up I'm planning to make at some point in future which should hopefully make it feasible, I'll re-visit the idea then.

Start another thread for multi core processors? Unless that's your major plan!

Jamish wrote:Start another thread for multi core processors? Unless that's your major plan!

The simulation already runs in its own thread but the state variables are all static, OOP purists would be shaking their heads in disbelief but the reduction in the number of the pointer deferences results in a significant performance increase. Each simulation would therefore have to be run in its own process, probably doable but I'd need to look into it. It might be easier to just provide i2c support using named pipes or something between two instances of the simulator running simultaneously.

Hey Myndale,
I have a new idea for your Simbuino.
How about implementing plugins (very easy on .NET) to e.g. allow to simulate different I²C devices.
So that users can easily add functionality to Simbuino and share that in the community.
I did that earlier and it is very easy.
Just load all plugins from a folder on start, call their init() function, pass them your objects like cpu classes and stuff and make events, so that they can do stuff e.g. on I²C read.
And the plugins can spawn windows, to configure them and read their output.