Thank you for sharing the source!

[Brendan Robert]

I like how cleanly you implemented some of the emulation aspects.  I wonder, though, there are some similarities to my emulator Jace (also available under the GPL.)  There are things you did that were also very different as well.  I still fight java for getting exact timing when sound is involved.  Do you have any tips on working with JavaSound?

Thanks!

-Brendan Robert

[Paulo Peccin]

You're welcome, thanks!

What motivated me to create Javatari was the challenge of making something totally from scratch.

I spent some time at home last year, and as I love to code, I came up with this idea to make an emulator.

I really did not know almost anything about the other emulators (yes, I knew Stella, but just played with it a few times in the past). As my intention was to build an emulator from scratch and using only standard Java, I did not care much about doing research about other emulators, libraries, etc.

I have not heard about Jace before!!! Is it also an Atari 2600 emulator?

At first, I thought Javatari was the first Java based 2600 emulator, but then later I found out about JStella. But it is just a port of Stella, so its not an original creation anyway.

Regards,

Peccin

[Brendan Robert]

Ok, seriously?!  I can totally understand if you never saw or heard of Jace.  It is a Java Apple Computer Emulator, also 6502 (well, 65c02).  But I am surprised you haven't looked @ the code because

   WE  CODE  ALIKE

...even the way that you and I write bit-level operators in the CPU core is the same.  It is of course entirely possible for this to happen (it is a very big planet) but just very unusual.   I was motivated by doing Jace from scratch, but also I really wanted to experiment with the new (well, new at the time) Java 5 language features.

Seriously!!  You and I do a lot of similar things, except I went totally crazy with using newer java 5 concepts like annotations and enumerations.   In the CPU core, I use a fixed-size array to represent each opcode, so every member of the array is an object that represents the command and address mode.  This way, there is no expensive case switch, as you found these are not very fast.

I implemented the memory bus very differently though.  When I started Jace, I wanted to add Mame-style cheats one day (and in fact Jace has MAME style cheats now!) -- If you re-implement your memory bus to use the PagedMemory model from Jace you should also be able to port over other jace features, such as the cheats and live memory view (memory spy).   The core memory object has the same methods that you already wrote for getting and setting a byte, except the implementation classes are structured to allow memory pages to be moved around and re-mapped.  This abstracts the remapping of memory pages so that you can put different parts of rom or ram in different locations without memory copy.  Also, there is a very robust event model in Jace which is triggered by memory.  The Apple // architecture uses a lot of I/O ports and so on, so I implemented I/O read/write as memory events that listen on specific addresses.  This same memory event model makes MAME-style cheats very easy to do!

I have to applaud your work though -- I was always fighting with stupid JavaSound issues, and in fact I still have audio skipping sometimes.   Your approach is a lot more straightforward.

I hope there is some way we can collaborate in the future.  I really enjoyed looking at how you structure your code.  Again, excellent work and congrats on version 3.0!

-Brendan

[Paulo Peccin]

Wow, that is amazing!

Really, I can totally assure you that I never saw Jace before. I did not have a look at it yet to be honest. I am a little rushed at work right now and already invested a little too much time in Javatari in the last weeks.  :-(

When I started Javatari, I tried to make the design as close as possible to the real hardware. I imagine you had the same approach, maybe that ended up making our designs alike! Sometimes I feel that there is not really a lot of different ways of implementing really simple and elegant code for a particular problem.

I really do not like much to use pre-made code and libraries... I am already forced to do it at work. :-)

But for a home project, where would all the fun go if you just plug dozens of libs? I like to design and code, not just integrate.  :-)

Also at work, I am always the guy that prefers simple homebrew solutions over heavy libs from the market.

In the first version, I also made the design using a little more "features" of Java, like Enums, switches, and so. If you look at the first versions of the source you'll see. Then I did some performance experiments and decided to wipe out the Enums and switches from the critical parts of the code. That gave me a good boost in performance.

The Atari 2600 has only 128 bytes or RAM (thats right, not 128K, just 128 bytes), so I did not invest too much at this area.

The more complex part is the various cartridge "mappers" out there, Because the 2600 can only see 4K of ROM at a time, the bigger games have to do bankswitching. And almost each company invented their own way of doing it when releasing their cartridges.

I also plan to offer memory cheats at sometime, but will do it in a very simple way since there is only 128K of memory. In fact, some cartridges have extra RAM also.

The biggest challenge for me is making people want to give a chance and look a little away from Stella, the most popular emulator, so they can see Javatari. What really makes Javatari different (and better in those aspects) than Stella is that its Java based, so its much more portable and can be deployed on line.

And..... of course..... Multiplayer mode! 

Have you tried it? You must see it working on a local area network, preferably. Its really amazing!!!

As I said, I did not do much research about existing emulators, but I believe this multiplayer mode is exclusive for a 2600 emulator.

I don't know if you know how the Atari 2600 works besides the CPU. It is a CRAZY machine, with NO VIDEO BUFFER. The game has to follow the CTR beam all the time and fire events that trigger the display of objects at the current beam position! It is a precision and timing nightmare...

That is the most complex part of the emulator.... The video chip.

Try to enter the various Debug Modes (ALT + D), and you will see the important events as colored pixels on the screen. Also, enlarge the display with Ctrl-Shift-Arrows so yo can see the non-visible parts of the video signal.

The 2600´s video chip does not know what a frame is. It can only generate lines, and it is up to the game and CPU to control how much lines to draw, and to command the Vertical Blank and Synch signals sent to the TV.

Very unusual but very simple and elegant, for its time!

Last year I created a Power Point presentation for my colleagues, explaining how the Atari 2600 works internally and also a little of the Emulators design. I presented it it an internal technical event in the company I work.

I can sent it to you if you'd like to see it, but unfortunately it is in Portuguese.

Regards,

Peccin

[Brendan Robert]

On Thursday, January 24, 2013 8:23:04 AM UTC-6, Paulo Peccin wrote:

Wow, that is amazing!

Really, I can totally assure you that I never saw Jace before. I did not have a look at it yet to be honest. I am a little rushed at work right now and already invested a little too much time in Javatari in the last weeks.  :-(

I know what you mean.  I have the same struggle.

 

When I started Javatari, I tried to make the design as close as possible to the real hardware. I imagine you had the same approach, maybe that ended up making our designs alike! Sometimes I feel that there is not really a lot of different ways of implementing really simple and elegant code for a particular problem.

Yes!!  I can appreciate that.  It is also more difficult to get others to use a java program if they have to launch the program with a specific classpath.   Jace is also self-contained with JDK-only class dependencies.

 

I really do not like much to use pre-made code and libraries... I am already forced to do it at work. :-)

But for a home project, where would all the fun go if you just plug dozens of libs? I like to design and code, not just integrate.  :-)

Also at work, I am always the guy that prefers simple homebrew solutions over heavy libs from the market.

I keep getting really tempted to use some bits of Spring because they are great at self-discovery and what not.  But I managed to come up with a "good enough" solution without them for now.

In the first version, I also made the design using a little more "features" of Java, like Enums, switches, and so. If you look at the first versions of the source you'll see. Then I did some performance experiments and decided to wipe out the Enums and switches from the critical parts of the code. That gave me a good boost in performance.

 Enums slowed it down?  Oh no!  I need to look in to that!!

The Atari 2600 has only 128 bytes or RAM (thats right, not 128K, just 128 bytes), so I did not invest too much at this area.

The more complex part is the various cartridge "mappers" out there, Because the 2600 can only see 4K of ROM at a time, the bigger games have to do bankswitching. And almost each company invented their own way of doing it when releasing their cartridges.

This is true, but to the 6502 all it sees is a 64KB address space.  The Apple // series also has an odd bank-switching scheme since it has 64kb ram but it also has 4K I/O space (C000-CFFF) and 12K of rom from (D000-DFFF) so it has all these I/O softswitches that tell the MMU to swap in either RAM or ROM in the upper banks and so on.  I think what you see in the Atari and in the Apple was pretty common across a lot of 8-bit platforms.

I also plan to offer memory cheats at sometime, but will do it in a very simple way since there is only 128K of memory. In fact, some cartridges have extra RAM also.

The biggest challenge for me is making people want to give a chance and look a little away from Stella, the most popular emulator, so they can see Javatari. What really makes Javatari different (and better in those aspects) than Stella is that its Java based, so its much more portable and can be deployed on line.

Having the browser option is a good bet.  That's where you'll get a lot of folks interested who would otherwise not bother taking the time to figure out how to start it from the command line. 

And..... of course..... Multiplayer mode! 

Have you tried it? You must see it working on a local area network, preferably. Its really amazing!!!

This is an awesome feature.  I'm curious though, how do you keep the clients in sync?  Even a slight amount of lag, 50ms or so, is enough for the emulator state to skew on both sides.

 

As I said, I did not do much research about existing emulators, but I believe this multiplayer mode is exclusive for a 2600 emulator.

I've seen it in some NES emulators -- It's awesome that you got it working in Atari also!  The only thing about managing ports in Java is that it isn't very good at catching disconnects.  I had to write ACKs in my networking code to trap this.   I do not have network play in my emulator, but I do have some networking features.  In Jace you can emulate a serial port and on the PC host side it listens on a TCP port so you can telnet in to the emulated machine!

 

I don't know if you know how the Atari 2600 works besides the CPU. It is a CRAZY machine, with NO VIDEO BUFFER. The game has to follow the CTR beam all the time and fire events that trigger the display of objects at the current beam position! It is a precision and timing nightmare...

That is the most complex part of the emulator.... The video chip.

I can imagine!  I've seen developers talk about it, and there's a great book called "Racing the gun" which goes into great length to describe this.  Yes, it is absolutely crazy!  The Apple has a framebuffer, but it is not exactly linear.  This makes it a little difficult to program, but not nearly as tricky as Atari.

Try to enter the various Debug Modes (ALT + D), and you will see the important events as colored pixels on the screen. Also, enlarge the display with Ctrl-Shift-Arrows so yo can see the non-visible parts of the video signal.

The 2600´s video chip does not know what a frame is. It can only generate lines, and it is up to the game and CPU to control how much lines to draw, and to command the Vertical Blank and Synch signals sent to the TV.

Very unusual but very simple and elegant, for its time!

Yes, the big thing was the low part count.  This was key to Atari having a low-cost way to mass produce the system at an affordable price.

 

Last year I created a Power Point presentation for my colleagues, explaining how the Atari 2600 works internally and also a little of the Emulators design. I presented it it an internal technical event in the company I work.

I can sent it to you if you'd like to see it, but unfortunately it is in Portuguese.

This is something you can do that I can not: Speak Portuguese.  :-D  I think it's awesome that your co-workers wanted to know more about Stella.  It's amazing for its time, and especially for the low part count on the board.

Have you had the time to check out Wudsn yet?  If you use Eclipse, I think that Wudsn will be your new best friend.  :-D  The author, Jac, is a pretty cool guy and always responds to email if you need help.

-Brendan

[Brendan Robert]

This is true, but to the 6502 all it sees is a 64KB address space.  The Apple // series also has an odd bank-switching scheme since it has 64kb ram but it also has 4K I/O space (C000-CFFF) and 12K of rom from (D000-DFFF) so it has all these I/O softswitches that tell the MMU to swap in either RAM or ROM in the upper banks and so on.  I think what you see in the Atari and in the Apple was pretty common across a lot of 8-bit platforms.

ACK!  I said something incorrect.  The 12K of rom in the Apple is D000-FFFF, not D000-DFFF.  Silly typo.  :-D

-B 

[Paulo Peccin]

The Atari uses the 6507, which is just like the 6502 but has only 13 address pins. So it can see only 8K of memory, replicated 8 times though 64K.

Regards,

Peccin

[Brendan Robert]

And yet it can still do things like this:

http://www.youtube.com/watch?v=XM1CbBePcdk&list=PL652AD1EDB3562BFB

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

http://www.youtube.com/watch?v=D7MyAzLZaIM&list=PL652AD1EDB3562BFB

[Paulo Peccin]

Yes!

I use these demos to test the emulator!  :-)

They do nasty and undocumented things to the machine.

I found several bugs with them!

Regards,

Paulo