fnuecke/circuity

circuity's Issues

Make addresses configurable

I.e. make the address change mode of the configuration item work.

• Open GUI client side which can be used to select a different address.
• Send address back to server.
• Apply address to device, check for collisions, handle accordingly.
  • Change and scheduleScan()?
  • Handle directly in setter without scan?
  • Scan resets all addresses on conflicts ATM to try resolving conflicts. Maybe require addressables to persist a "preferred" address?

Multi-CPU support

This is probably not a goal of the project but it sorta works already and there's not much that's required to make it work properly.

Basically, these things need to be done:

Step 1: Give CPUs a bus ID

Pretty self-explanatory. No actual API needs to be provided, just make sure there's at least one byte available.

Step 2: Make it possible for a CPU to know its own ID

Most logical approach: Add an I/O port to the bus controller to query the current component's bus ID.

Step 3: Add support for synchronisation primitives

Well, there's basically two things that need to be done here: one which covers just about every sync primitive and is nice and easy to implement and such an approach is only necessary for if we ever run stuff in different threads, and one which covers the sync primitive I and maybe ds84182 will be using and is a bit tricky.

Fun fact: Neither of these methods are used on the Z80.

Step 3a: Support for atomic locking

Only required if you actually run several CPUs on a thread, but x86, 680x0 and ARMv3+ at the very least will benefit from this.

If CPUs ever end up running on multiple threads, it may be necessary to be able to lock an address for atomic operations.

lockBus() and unlockBus(), perhaps? The other option is to use synchronized(bus.getLock()) { ... } which is a bit ugly on the encapsulation side but less likely to explode in your face, and because it's safer to actually use I prefer it.

It's probably OK to not require a lock on read, just grab the lock on write. The greatest portion of your data accesses are reads, so this shouldn't be a major performance hit, especially if your CPU implements a cache. If anything needs a lock to merely read from an address, it's probably an I/O device.

Anyway, this covers CAS, TAS, and various other locked atomic ops.

Step 3b: Support for LL/SC

This is what's used in several RISC CPUs (Alpha, ARMv6+, MIPS II+, PowerPC).

This will need an API. If this turns out to be wrong I'll be willing to jump in and fix it but here we go:

• On write, check the address against a mask (suitable default when not using LL/SC: llbase=1, llmask=0, lladdr=don't care, llcpuid=-1). If ((addr&llmask)^llbase)==0, then reset to default values. You may need further checks than this if you are supporting unaligned reads/writes on the bus - (((addr+size_in_bytes-1)&llmask)^llbase)==0 would make sense too.
• On LL (tentative sig: long readLL(int cpuid, long addr, long mask)), set llcpuid to cpuid, set llmask to mask, set llbase to (addr&~llmask), set lladdr to addr.
• On SC (tentative sig: boolean writeSC(int cpuid, long addr, long data)), ensure that cpuid==llcpuid. If this is true, then write and return true. Otherwise, don't write, just reset to default values and return false. Of course, your CPU is ultimately responsible for making sure that the SC address + width was the same as the LL address + width.

If you'd rather I implemented this, then please feel free to just create the sigs in a suitable spot and I'll fill them in. Suitable stubs for now: readLL just goes to read, and writeSC just returns false.

As much as it would be easier to just lock the bus when LL is used and unlock it when SC is used, this would mean that anyone could deadlock the game server, so this shortcut will not be an option.

---

Modularize all the things

Not much to modularize right now, but general plan is to have sevaral sub-mods for individual functionality/behavior.

• Core
  • APIs (bus API in particular), Utility classes (well, logically belonging to core anyway)
  • Bus cables
  • Default bus controller
• Computer
  • Built-in CPU architectures
  • RAM blocks
• Devices
  • Serial console
  • Graphics card
  • etc
• Energy
  • Injects components/capabilities into blocks from other modules to make them use energy
  • Power Supply Unit Block
• Hard Mode?
  • Injects components/capabilities into blocks leading them to be able to fail
  • E.g. decaying storage media
  • Stuff
• Robotics?
  • Simple robots/drones more akin in behavior to BC than OC's stuff

Plan is for the individual modules to be bundled in one Jar so as not to be annoying, but to give people the ability to disable them individually.

Allow devices to have an editable configuration

For now this would specifically be devices having the address of another device configured so that they can access it. E.g. for the CPU for loading an EEPROM from a specified address on boot, or the other way round, the EEPROM knowing to what address to copy its data on boot.

Add throttling to synchronization

Ideally, a configurable bandwidth usage cap per tick.

Replace the DeviceType enum with a string identifier

As suggested in another issue.

Allow changing data bus width in bus controller

And support it in devices where it may make sense (bus controller has to, RAM would be good to avoid needing multiple RAM blocks/items for different bus widths).

Allow changing address bus width in bus controller

This will basically just change the maximum address value / address range. No support for >20 bit for now tho, until someone can tell me an efficient way of mapping addresses without a lookup table...

Also add a way to query this via the bus controller.

Block models and block and item textures

Replace all of the placeholders with actual models and textures.

Prioritize pending synchronizations by distance to player

The further away, the less it generally matters if values are synchronized with a bit of delay. For example, would make nearby screens update smoothly while far away ones don't have to, reducing bandwidth use a bit.

Improved matching of list serializer

May currently miss associations of persisted to existing items when list changed (e.g. list of serializable components), leading to unnecessary data loss.

Add floppy disk drive / floppy controller

Implement a floppy controller bus device and add a floppy item.

Description

I understand that this is a real architecture , memory, machine code or what?

In-game serial console visualization

Add a GUI / in-world rendering of the serial console's output (instead of just dumping it to Java's stdout).

• Store current state of serial console.
  • How wide and high?
• Synchronize changes to client.
• Render to screen (requires #7).
  • Add font renderer? (Codepages would be good enough for this)

Add system for bus devices to have a persistent globally unique ID

Needed to allow bus devices to persist references to other bus devices.

• Add interface bus devices may implement to provide their UUID.
• Have bus controller keep list of devices by UUID and provide lookup.

InvalidStateException not supported on OpenJDK

Did you mean IllegalStateException?

It's in AbstractLinearLayout.java. Circuity compiles fine when I change it to that and remove the import.

If you're all OK with this I can push that change.

Add a GPU

Implement some sort of GPU, probably with VRAM mapped to general address space for access speeds.

All further details TBD.

• Render to screen (requires #7).

Add hard disk / disk drive controller

Implement a basic hard disk drive controller and add a hard disk item.

[RFC] API, Structure, Devices, Implementation

I'd love to get some feedback on pretty much everything in the mod at this point, but in particular the bus API and the bus controller behavior. I think it's headed in a reasonable direction that will give sufficient freedom, but my knowledge about other CPU architectures is rather limited.

Pinging @asiekierka, @iamgreaser, @ds84182, @magik6k.

If anyone else needs needs pinging, please do.

I can do a write-up of the current state and my thoughts, if you like, but that'll take a bit of time, so I'd like to see if there's interest at all, first :P

If anyone of you is interested in contributing, let me know, and I'll probably just give you push access to the repo.

Separate lib package into separate mod when things stabilize

Easier to test and fix stuff for now, but at some point separate it out so I can use it in other projects.

Block that can upload/download (at least) EEPROMs

Similar to the electronics library (or what it was called) in BC, a block that can be used to upload/download data from storage media.

Bonus: not only browse predefined directory but also allow selecting arbitrary files with a file chooser dialog? Kills fullscreen, but would be rather useful since it'll often be easier to cross-compile stuff and then upload it rather than compile it in-game.

Add a screen block

Should provide generic rendering of bus devices that provide graphical output.

• Add API that can be implemented on bus devices which can provide graphical output.
  • Will be called after OpenGL is set up (transforms etc.), so they just have to render on a 2D plane of a given size.
• Add possibility to bind screen to devices implementing the API (requires #6).
• Render in world.
• GUI?
  • Use GUIHandler (NetworkRegistry.INSTANCE.registerGuiHandler).