CUzeBox - The new official Uzebox emulator

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Artcfox »

Jubatian wrote: Sun Oct 01, 2017 12:16 pm
Artcfox wrote: Sun Oct 01, 2017 11:58 amI was just thinking that if someone passed a .uze or .hex (that is not a bootloader) as a parameter that it should always override whatever is in the coderom, since that is a unique case only to the emulator (being able to force it to run exactly this thing I pass you on the command line). The real hardware only has what's been flashed to it (the bootloader and/or a .hex file). You can tell right now whether something passed is a bootloader or not correct? (Based on where the code is loaded, IIRC) so I think that might be enough for the intended behavior. If a user wants to test the bootloader, they'll always pass in a bootloader hex file on the command line, otherwise, just force it to load a game directly as if there is no bootloader?
It overrides the area defined in the .hex or .uze file. If it overrode more, then there wouldn't be any point of persisting the ROM at all expect for supporting the current quirky bootloader, while this way it would be capable to support programs which store things in areas of the ROM not covered by the main binary (honestly I would happily ditch persisting ROM altogether, it is a rather useless feature beyond trying to work with the current bootloader).

The emulator is not capable to tell whether a file is a bootloader or not. It can assume that a .uze file is not a bootloader, but it can not make such assumptions on .hex files (the information which regions were written is lost across the interface).

For normal users these all shouldn't be a problem as they wouldn't load the bootloader (or if they have such a package, then would always use the bootloader).

I wouldn't want to put any effort in trying to mess with this any more for now. Better invest that effort in creating a bootloader which works better and forget about these problems.
Gotcha. If these things will all be solved with a new better bootloader, then you're right, it's better to not waste time trying to support the old broken one.

The coderom persisting is the only thing that allows the Android port to work, so please don't remove that.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Jubatian »

I discovered a problem with publishing binaries on the forum.

The links the forum generates don't refer to the file name, rather the ID which the forum assigns to the upload. This makes it impossible to keep an attached file updated since doing that assigns a new ID to it. The file may appear the same, but the ID is different, the link's target is different.

So as of now, somebody would have to host these binaries. I will keep them up to date here:

http://files.jubatian.com/cuzebox_linux_amd64.tar.bz2
http://files.jubatian.com/cuzebox_windows_x86.zip
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Artcfox »

Uze offered to host them on uzebox.org, and Lee and I are in the process of setting up an automated build server that would build binaries for all OSes upon changes to the Git repo (keeping old binaries in case there is a problem).

I have posted the cross-compiled OS X binaries for 32 and 64 bit processors, but the idea is to automate that process.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: CUzeBox - a new Uzebox emulator in progress

Post by CunningFellow »

How difficult will it be for me to add USART0 Transmit complete interrupt functionality?

I remember I had to hack Uzem to add TIMER1 Overflow Interrupt when I developed T2K.

I'm doing something now as I come up to speed that I want the USART0_TXC interrupt for.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Jubatian »

CunningFellow wrote: Tue Oct 10, 2017 9:52 pm How difficult will it be for me to add USART0 Transmit complete interrupt functionality?

I remember I had to hack Uzem to add TIMER1 Overflow Interrupt when I developed T2K.

I'm doing something now as I come up to speed that I want the USART0_TXC interrupt for.
I see in the other topics what you want it for, okay! For now I say just fork off CUzeBox and hack what you need into it (Lee might have made some UART code already though part of his ESP8266 attempt, although that might have no cycle level accuracy). If you just need to fire a timer, add it it to the appropriate port write (cu_avr_writeio()), the hardware event processor (cu_avr_hwexec()) to receive it, and the interrupt processor (cu_avr_itcheck()) to handle it. Other peripherals should serve as good examples for it.

It wouldn't incur a slowdown to add it since it would plug into the hardware event system especially designed for this purpose: if there are no HW events in a clock cycle, no checks are made for them, only when the next event target is reached. So CUzeBox can eventually receive an accurate UART emulation (just like it can emulate SPI), I just don't want to mess around with it now having several other tasks.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: CUzeBox - a new Uzebox emulator in progress

Post by CunningFellow »

Thanks. I think I understood the workings of Cuzebox enough to add the USART complete interrupt.

I did not make it general purpose. It ignores the control registers for baud/data_length/stop_bits etc.

All it does is trigger an interrupt 1304 cycles after a write to UDR0. This is only the correct value for 1-7-N with UBRR=9. It is also only correct with UDR and UBRR being written in consecutive instructions.

If it isn't correct - it is at least correct enough to have Cuzebox agree with AVRStudio :)

I can now resume development with Cuzebox without having to resort to cycle counting and real hardware.

Code: Select all

commit fc7a828cfef09f85977a3a3d542076f783179d5b
Author: Bob Bobson <bob@bob.com>
Date:   Fri Oct 13 06:46:51 2017 +1000

    Added brain dead UART0 TX complete emulation

diff --git a/cu_avr.c b/cu_avr.c
index d86feab..ee625fe 100644
--- a/cu_avr.c
+++ b/cu_avr.c
@@ -244,6 +244,8 @@ auint           wd_interval_end[2];
 #define VECT_T1OVF     0x001EU
 /* SPI */
 #define VECT_SPISTC    0x0026U
+/* USART0_TXC */
+#define VECT_USART0_TX 0x002CU
 
 
 
@@ -365,6 +367,25 @@ static void cu_avr_hwexec(void)
 
  }
 
+ /* USART0 peripherals (RLE mode end scanline) */
+
+ if (cpu_state.usr0_tran){
+
+  if (cpu_state.cycle == cpu_state.usr0_end){
+
+   cpu_state.usr0_tran = FALSE;
+   cpu_state.iors[CU_IO_UCSR0A] |= 0x40U; /* USART0 TX complete flag */
+   event_it = TRUE;
+
+  }else{
+
+   t0 = WRAP32(cpu_state.usr0_end - cpu_state.cycle);
+   if (nextev > t0){ nextev = t0; }
+
+  }
+
+ }
+
  /* SPI peripherals (SD card, SPI RAM) */
 
  if (cpu_state.spi_tran){
@@ -547,6 +568,12 @@ static void cu_avr_itcheck(void)
   event_it_enter = TRUE;
   event_it_vect  = vbase + VECT_T1OVF;
 
+ }else if ( (cpu_state.iors[CU_IO_UCSR0A] & 0x40U) !=    0U ){ /* USART0 dodgy timer interrupt */
+
+  cpu_state.iors[CU_IO_UCSR0A] ^= 0x40U;
+  event_it_enter = TRUE;
+  event_it_vect  = vbase + VECT_USART0_TX;
+
  }else{ /* No interrupts are pending */
 
   event_it = FALSE;
@@ -762,6 +789,16 @@ static void  cu_avr_write_io(auint port, auint val)
    cycle_next_event = WRAP32(cpu_state.cycle + 1U); /* Request HW processing */
    break;
 
+   
+  case CU_IO_UDR0:    /* USART0 data */
+   cpu_state.usr0_tran = TRUE;
+   cpu_state.usr0_end  = WRAP32( cpu_state.cycle + 1304 );
+   if ( (WRAP32(cycle_next_event  - cpu_state.cycle)) >
+        (WRAP32(cpu_state.usr0_end - cpu_state.cycle)) ){
+    cycle_next_event = cpu_state.usr0_end; /* Set USR HW processing target */
+   }
+   break;
+
   case CU_IO_SPDR:    /* SPI data */
 
    cpu_state.iors[CU_IO_SPSR] &= ~0x80U;
diff --git a/cu_types.h b/cu_types.h
index ad145e1..ec0dfb1 100644
--- a/cu_types.h
+++ b/cu_types.h
@@ -119,6 +119,8 @@ typedef struct{
  boole spm_prge;      /* SPM erasing or programming in progress */
  auint spm_mode;      /* SPM selected mode for the next SPM instruction */
  auint spm_end;       /* SPM enable end cycle */
+ boole usr0_tran;     /* USART0 transfer in progress */
+ auint usr0_end;      /* USART0 transfer end cycle */
 }cu_state_cpu_t;
 
 
Edit: Fixed up the patch with the error Jubatian pointed out with the SPI/USR cut and paste mix up.
Last edited by CunningFellow on Sun Oct 15, 2017 1:59 am, edited 1 time in total.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Jubatian »

CunningFellow wrote: Thu Oct 12, 2017 10:18 pm Thanks. I think I understood the workings of Cuzebox enough to add the USART complete interrupt. (...)
Code seems all right, except for one thing: "cycle_next_event = cpu_state.spi_end; /* Set USR HW processing target */" That' should be "usr0", guess a typo, but it would mess up things for you (missed event) if the UART timeout would be your next HW event (it likely works since the timeout is so long that other events occur before that, and in the HW event processor you set the target right).

So if you set the timeout right (by cycle count), then this patch should do it fine for your development! (And you can imagine, a complete UART emulation would just add code without any significant performance overhead :) )
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: CUzeBox - a new Uzebox emulator in progress

Post by CunningFellow »

Good spotting. I missed that "SPI" in my hasty cut and paste.

I did not affect me as the USART Interrupt will never be the "next event" and there will always be a few TIMR1_OVF before that.

So the fact that I got the line

t0 = WRAP32(cpu_state.usr0_end - cpu_state.cycle);

correct saved me from my stupidity.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by nicksen782 »

Question: When/will the adaptions made by CunningFellow be added to CUzeBox?

Feature suggestion: In my game I have often wanted to be able to visualize when the SD card or SPI RAM is being used. I do it now by checking each vsync for the state of each devices CS pin. Could these indicators be added to CUzeBox?
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Jubatian »

nicksen782 wrote: Thu Dec 07, 2017 7:38 pm Question: When/will the adaptions made by CunningFellow be added to CUzeBox?

Feature suggestion: In my game I have often wanted to be able to visualize when the SD card or SPI RAM is being used. I do it now by checking each vsync for the state of each devices CS pin. Could these indicators be added to CUzeBox?
I will likely create an adequate USART emulation in the end of the year, the mod made by CunningFellow is a simple hack only realizing what is needed for his video mode development (I will use his video mode to confirm timing when doing the real USART). So likely when CunningFellow releases some game demo, there will be an emulator release capable of running it.

I will look at SPI RAM / SD state indicators later, although there is very little visual room left on CUzeBox's display. Maybe a complete redesign of the GUI will be necessary which I am not very motivated to start nowadays, even more interested in fixing up stuff in the Wiki (which I think is more critical nowadays that the emulator as honestly some parts of it are very messed up), but I also would like to create games & video modes. The SPI RAM as far as I experienced so far is a very simple well behaving peripheral, I never needed any debug for it. The SD card could really use some debug support though (in this regard I also would like to settle remaining matters with the new bootloader so I can finalize the API library, still waiting for some feedback on it).
Post Reply